On Mar 11, 2009, at 4:46 PM, Glenn Lagasse wrote: > Hey Karen, > > * Karen Tung (Karen.Tung at Sun.COM) wrote: > > Thanks for the feedback! > > <SNIP> > >>> So, thoughts? >>> >>> Thanks! >>> >>> >> Hi Glenn, >> >> Personally, I like the idea of having the code for generating the >> checksums be part of same script that creates the images. Like you, >> I see a strong link between the 2 activities. >> >> However, I don't like the pre-defined set of crypto algorithms. >> I think we should allow ppl to choose which algorithms they want to >> use. >> >> I like the idea of adding the following to the manifest >> >> <iso_checksums> >> <cksum_type="md5"/> >> <cksum type="sha1"/> >> ... >> </iso_checksums> >> >> Perhaps checksum generation will be off if that section is missing or >> empty. If it is not empty, then, we generate checksum for all the >> algorithm specified. This provides the most flexibility, and people >> can pick and choose which checksum to generate, if any at all. > > I don't feel strongly one way or the other about this. On the one > hand, > a simple toggle (enable checksums) appeals to my 'keep things simple' > mindset. Especially given that I believe the default set of checksum > types I've envisioned is pretty complete (no one I know of generates > hashes greater than sha256 for any media distribution) and doesn't > impact construction time in any appreciable way. On the other > hand, specifying which checksum types you want to generate appeals > to my > 'allow the user to dig as big a hole as he'd like' (as it were) > mindset. > > Any one else have more thoughts on this? >
What's the design philosophy behind the OpenSolaris installer? Simple? Dig a hole? Extensible? What's the 80% case? >> Also, I don't think there needs to be a separation for iso_checksums >> or usb_checksums. Perhaps just 1 checksum section is enough? The >> same crypto algorithm can be used for different type of images, iso, >> usb, or even the future virtual box images. > > The only reason I thought of seperating between the ISO and USB is > it's > more flexible. It's conceivable that someone may want to generate > checksums only for one image type. We could make this an all or > nothing > (if you specify checksums then each image type gets those generated) > proposition. That keeps it simple for now and if there's a need we > could expand the manifest to specify checksum types per image type. > That might be a nice compromise between a simple implementation and a > more complex one. It could certainly start to get out of hand if we > start adding more image types that need checksums (ISO, USB, VB Image, > whatever else comes down the road) that we would have to add to the > manifest. > What's the use case around generating several kinds of images, but only requiring checksums for some of them, or generating different checksums for different kinds of images? Common?
