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

Re: Package/Mirror integrity?

Christian Hammers <ch@westend.com> writes:

> As far as I know there's no possibility to actually apply such a binary
> signature to a .deb yet. If I'm wrong please point me someone to the 
> relevant docs :)


There exist several tools out there for the purpose of handling
cryptographically-signed .debs.

These tools are: 1. debsigs; 2. debsig-verify; 3. dpkg plus
verification patches; 4. apt-checksigs.  These tools are being
developed jointly by Progeny and Debian developers.  Here is what the
tools do:

1. debsigs

   This package is used to add, delete, list, etc. signatures
   on .deb packages.  Its primary purpose, though, is to add
   signatures.  It comes with a separate program, debsig-autosign,
   that can add signatures in cases where this needs to be
   done automatically, though that tool is still somewhat immature.

2. debsig-verify

   This is the signature verification component.  Given a .deb,
   it will look up policy documents that describe what sort of
   signatures are expected to be present, from whom, and various
   other criteria that must be met to consider the package to be
   cryptographically verified.  By using separate policy files
   for each .deb distributor, the user can successfully verify,
   on a single system, packages from multiple origins -- eg.
   Progeny and Debian.

3. dpkg plus verification patches

   In its current form, this means several things:

   * If debsig-verify is installed, dpkg will try to verify
     the signature on each deb when performing an install (-i).
     If the signature check fails, dpkg will abort without installing
     the package. 

   * dpkg-dev is modified to include a hook to call debsigs
     to add a cryptographic signature to the .deb at build time,
     though this facility is still rudimentary.

   * dpkg has two new options: --force-missing-sigs and
     --force-bad-sigs, which force installation of packages
     without any signatures and those bearing bad signatures,

4. apt-checksigs

   This tool is to allow the end user to control signature checking
   on a per-repository basis.  Basically, that means that
   --force-missing-sigs can get passed on to dpkg automatically
   for those repositories that do not carry signed .debs.
   While the security implications of doing such a thing should
   justifiably give people significant pause, apparently there
   is significant demand for it nonetheless.  This should also
   have the advantage that the signatures get checked before
   being passed to debconf for preconfiguring, which would
   otherwise be one avenue of attack.

Progeny is aggressively working on implementing these features.  To
date, I haven't seen lots of discussion in Debian about it.

Where to find code?  Well, right now, since it's still being
aggressively developed, it's scattered.  debsig-verify is in Debian's
dpkg CVS and non-us as module debsig and debsig-verify, respectively.
debsigs is in non-us.  dpkg diffs should be floating around on mailing
lists somewhere.

Progeny has applicable policy files and keyrings ready to verify our
packages in the Progeny package progeny-keyring, in our archive on
archive.progeny.com/progeny.  Testing code can be found at
http://www.indy.progeny.com/~branden/repository/, which includes
debsigs, debsig-verify, dpkg, and apt-checksigs.

A technical overview, such as it exists, of the system can be found at
gopher://gopher.quux.org:70/11/devel/debian.  This is somewhat outdated,
and incorrect in several respects by now, but is the best that
currently exists.  The system is extremely flexible, and each site
implementing it will want to come up with its own guidelines for what
signatures get applied and by whom, and what constitutes a verified

The principle people working on projects are:   (others work on them too)

debsig-verify: Ben Collins
debsigs: John Goerzen
dpkg patches: John Goerzen
apt-checksigs: Branden Robinson
integration testing: Branden Robinson and the Progeny QA team

Hope this helps!

John Goerzen <jgoerzen@complete.org>                       www.complete.org
Sr. Software Developer, Progeny Linux Systems, Inc.    www.progenylinux.com
#include <std_disclaimer.h>                     <jgoerzen@progenylinux.com>

Reply to: