Subject: Re: BPG call for use cases
To: Curt Sampson <email@example.com>
From: Simon J. Gerraty <firstname.lastname@example.org>
Date: 07/31/2005 01:50:26
>> I'm late to the party again, but fwiw, I've been using "signed"
>> packages at work for sometime. This is typically done as a wrapper
>> package - that contains the original .tgz and a .tgz.sig and the bits
>> needed to verify it. Customers can only access the "signed" packages
>> For more recent packaging, the .sig's are an integral part of the
>> packaging and are verified by the +INSTALL script.
>Can you explain the details of how you're doing this?
Simply add a function to a common header that you put into each +file
to verify files - with a preference for .sig rather than .sha1 and
.sha1 rather than .md5
As long as you follow the convention that each file will have a
file.sig, file.sha1 etc the above function is quite simple.
As for .sig's these are generated by the equivalent of a simple openssl
commandline, and verified in a similar manner (though I actually use
a binary with a built in trust store - since I have to avoid attempts
to spoof the signature verification...) but the intent is that paranoid
customers can verify the .sig's via alternate means if they wish.