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.
