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 :)
Christian,
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,
respectively.
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
package.
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: