[caiman-discuss] Code review request for bug 5265

[Glenn Lagasse]

* 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