* Dave Miner (dminer at opensolaris.org) wrote: > Glenn Lagasse wrote: >> Hey Dave, >> >> * Dave Miner (dminer at opensolaris.org) wrote: >>> Glenn Lagasse wrote: >>>> Could I get a reviewer (or more) to have a look at the changes I'm >>>> proposing for 5265 (Distro constructor should auto-generate image >>>> hashes) please? >>>> >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5265 >>>> http://cr.opensolaris.org/~glagasse/slim_source/ >>>> >>>> In case anyone is curious, I'm generating MD5, SHA-1 and SHA-256 >>>> cryptographic hashes. SHA-256 may be a little overkill but it's *more >>>> secure* than the others and I figured I'd try and appease the security >>>> conscious crowd while I was at it (SHA-256 checksums are also starting >>>> to show up in the wild from other distributors of electronic media such >>>> as ours so I figured I'd get a jump up). >>>> >>> I'd suggested this be an option controllable in the manifest, which >>> perhaps is overkill, though on many systems it's going to be a bit >>> time-consuming to compute three different hashes on gigabyte-ish >>> files. That could also be accomplished somewhat more obliquely if >>> this were made a separate step in the finalizer, at least; any >>> reason you didn't choose that design? >> >> I did actually consider those designs (manifest option, finalizer >> script). In the end I didn't really see any compelling reason to >> implement them. They're more flexible certainly but I didn't think this >> sort of feature needed that. I considered image checksums part of the >> same process of preparing the image done in create_{iso|usb}. I suppose >> it's possible that someone may not want to generate checksums for their >> images. In my testing (on a quad core 2 duo with 8g of ram) generating >> checksums took on the order of seconds to generate the hashes for the >> liveCD and usb images (less than 20 for a complete set for both) so I >> didn't consider time as a significant issue even if you consider >> building on 'slower' hardware. >> > > Thanks for elaborating. Some of this could have been in the bug > comments :-)
<grin> Yes, point taken. >> But, it's not difficult to implement either of the other designs. I >> think I'd lean more towards a combination of both, specify which hashes >> you want in the manifest which a new finalizer script then parses. You >> then have flexibility in deciding which hashes you want generated as >> well as checkpoint/resume ability when generating them. >> >> How does that sound? >> > > I think it sounds good. The main point to keep in mind is that we > should keep the finalizer tasks as modular as is sensible, as they give > us more flexibility in using those components. We've violated that in > some areas, but it would be good to not do so unnecessarily. Understood. I'll start working on this design then. Thanks Dave. Glenn
