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 :-) > 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. Dave
