[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#540215: Introduce dh_checksums

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.

Attachment: signature.asc
Description: Digital signature

Reply to: