Re: Revival of the signed debs discussion
On Mon, Dec 01, 2003 at 03:30:58PM +0100, Thomas Viehmann wrote:
> However: As "md5sum my.deb ; ar q my.deb _deb_signature ; ar d my.deb
> _deb_signature ; md5sum my.deb" gives two different lines, I'd think
> signing the individual members of the deb, not the deb in itself is
Please check out the debsigs package. I wrote it when I worked at
Progeny back in 2001, and Branden Robinson maintains it these days. It
does exactly that.
After installing debsigs, please reference the two text files in
/usr/share/doc/debsigs. debsigs.txt.gz describes how Debsigs works, and
signing-policy.txt.gz provides a draft signing policy I wrote for
Progeny.
Debsigs generates its signature by effectively cating the control and
data components of the ar file together, running that through gpg, and
storing the resulting signature data in a new component of the ar file.
I did test this back in 2001 and the code caused no problem for dpkg
extraction. In short, if a system does not use debsigs, the whole
signature is invisible to the system tools.
debsigs-signchanges is provided to help with that common case.
Debsigs also provides the ability to add multiple signatures to a .deb.
It is contemplated that this could be used to store, for instance, a
developer signature, an "installer" signature, etc. The developer
signature would be manually generated, and the installer signature would
be automatically generated. In this way, an end user could verify that
the .deb did not change since it left the developer's disk -- and that
it is a .deb that actually passed through dinstall. All of these
verifications are possible with only a keyring. There is no need to
verify MD5s from other files, etc. If you have a current keyring, you
could take a random .deb from a floppy and verify its integrity.
Reply to: