On Sat, Mar 20, 2010 at 01:27:52PM +0100, Harald Braumann wrote: > On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote: > > Harald Braumann <harry@unheit.net> writes: > > > On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote: > > > > >> You add an additional ar member that contains the signed checksums of > > >> all of the files in data.tar.gz, possibly another additional member > > >> that contains the signed checksums for control.tar.gz, or you document > > >> some convention so that you can combine both into the same signed > > >> checksum document. > > > > > Wouldn't it be simpler to just extract *sums from control.tar.gz, create > > > a detached signature for it and put it in the ar archive, instead of > > > extracting data.tar.gz and generating the sums a second time? Or would > > > this replace dh_*sums during package build time? > > > > I think it would replace dh_*sums during package build time and make > > obsolete including md5sums in the control.tar.gz. You don't really want > > the signature and checksums to be inside one of the other data members > > since that breaks, as Wouter points out, the ability to remove the > > signature and checksums and verify against the original *.changes file. > > And there's no need to include two copies of the checksums. > > There would only be one additional file, containing a detached > signature for the checksum file. No duplication of checksums and it > can easily be removed from the ar. But doing everything in one step, > like you proposed, is better anyway. Yes, agreed; detached signatures are probably better, since they would allow for multiple signatures without the requirement of having several copies of the checksums file in the .deb. What's more, if the checksums are still in the control.tar.gz, this would provide some level of backwards compatibility with a version of dpkg that doesn't support the detached signatures yet (i.e., a package installed with that version would still have the checksums on disk, though not the signatures). Since I haven't seen any input from the dpkg developers to this thread (-dpkg Cc'ed for their benefit), and since we seem to have hammered out a proposal that would involve some change to dpkg, let me summarize the proposal and ask for their input. The idea would be to provide a path from a binary on disk to a GPG signature for installed packages of which the user no longer has the .deb file from which it was originally installed, nor the Packages and/or Release.gpg file that was used to download it. The proposal as it currently stands would be that: - md5sums are phased out in favour of a more generic 'checksums' file that would use a more secure hash algorithm than MD5 (one of the SHA* family of hashes would probably do at the moment). - When asked to sign a .deb file, dpkg(-deb) would extract the checksums data member from control.tar.gz, create a detached signature for that file, and store it as an additional data member in that .deb. The benefits of this method as opposed to storing the signature in the control.tar.gz file would be: - Autobuilders would not need to be modified to support signed packages. - Adding a member to an ar file and removing it again later can be done in a way which is idempotent; the same is not true for modifying a tar file. As such, it is trivially possible to remove signatures from a .deb file to allow its verification against the original .changes file that was used for its upload, should this at any point be necessary - If adding multiple signatures is possible in a way which does not modify the contents of the .deb file itself, then the archive-wide key could in theory be used to sign individual .deb files. While a massive increase of CPU power on ftp-master.d.o would be needed to support this, it would allow for easier key management on the end-user end. - It would not break backwards compatibility. I tried this, by manually adding a file "signature_01.asc" to a .deb file; dpkg was still able to install this package, it just ignored the unknown file. If we're going to sign .deb files, then it would make sense to also sign the metadata and maintainer scripts in the control.tar.gz file. Doing this would require some way to clarify the difference between data in control.tar.gz and data in data.tar.gz; current suggestions are to either use a prefix (something like CONTROL:preinst, for instance) or to use the path of the binary-as-installed (wherein the above would become "/var/lib/dpkg/info/<package>.preinst"). There aren't any strong feelings towards one or the other, however. What's the opinion of the dpkg maintainers on this? -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Attachment:
signature.asc
Description: Digital signature