DeveloperWiki:Package signing

From ArchWiki
Revision as of 18:17, 29 May 2011 by KerrickStaley (Talk | contribs)

Jump to: navigation, search

Tango-document-new.pngThis article is a stub.Tango-document-new.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:DeveloperWiki:Package signing#)

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:DeveloperWiki:Package signing#)

This page will act as a brain dump and collaborative design document for implementation of package signing in pacman.

Aim

Implement package signing in pacman.

Why sign packages?

Because it makes it significantly more difficult for an attacker to cause you to install malicious packages.

Currently implemented signing functionality in pacman and associated tools

  • makepkg can sign a package
  • repo-add can add said signature to the database and sign the database
  • pacman-key exists for the sake of managing keys, but there is missing functionality
  • pacman can verify package signatures from repos, detached (.asc) package signatures, and signatures of the repos themselves

How signing is implemented in other distributions

Frugalware

Frugalware uses a fork of pacman which implements package signing (verify)

Gnuffy

Arch based distro gnuffy uses signed packages with their custom package manager Spaceman modeled on pacman.

Debian

Binary packages (.deb)

To sum up, the GPG signature is included in the .deb.

Details:

Regular non signed binary packages are "ar" archives of at least 3 files:

  • data.tar.gz (files to be installed)
  • control.tar.gz (package metadata)
  • debian-binary (contains the version of the deb format)

Signed packages also have a _gpgorigin file at the root of the .deb that is a "gpg -abs" of the concatenation of the 3 laters (as explained here):

cat debian-binary control.tar.gz data.tar.gz > /tmp/combined-contents
gpg -abs -o _gpgorigin /tmp/combined-contents (-a "Create ASCII armored output" ; -b "detach signature" ; -s "sign")

Source packages

Original files are provided on the repo like this acpid_2.0.4.orig.tar.gz with diff if necessary (acpid_2.0.4-1.diff.gz). A description file containing MD5sums of the orig.tar.gz and diff.gz is written and signed using GPG and uploaded along these.

Gentoo

Redhat/Fedora/CentOS

  • Signature type: GPG
  • Stored: in the RPM

A RPM package is a tarball of installed files to which is added a header made up of metadata (name of package, version, ...). This metadata can contain a GPG signature of the tarball. See the file format specification for details.

NB: packages built for the RedHat Network are signed with the RedHat official key(s) but technically a RPM can be signed using any other key (one can even add another signature to the RPM)

To check a package correction, one must first import the signer's key first: Example for RedHat

rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY

And can then check signature manually:

$ rpm -K openldap-clients-2.3.43-4.x86_64.rpm 
  openldap-clients-2.3.43-4.x86_64.rpm: sha1 md5 OK

And even fully check the package (MD5):

$ rpm -Kv openldap-clients-2.3.43-4.x86_64.rpm 
  openldap-clients-2.3.43-4.x86_64.rpm:
     SHA1 header hash: OK (65999383ad859be0ce337aee4c1f6bd049ebe4a0)
     MD5 sum: OK (4be23a341d23b794d08fbee35c459c83)

Option --nogpg prevents rpm from checking GPG signatures

Pros

  • Enable Official Distribution package signature but also enables personal and multiple signatures

Cons

  • Implies complicated package format with header containing signature of an inner tarball (not very KISS)
  • Space greedy on repos

Suse

Slackware

Ubuntu

For each package, a small description file containing the SHA sum of the package is created. That file is then signed using gpg (.dsc) and uploaded within the same folder as the package:

gpg --clearsign description_of_package

See result for acpid in Ubuntu

Cons

  • Space greedy (2 files for 1 package)

Ideas

SSL key chain

GPG

Seems to be the solution used by a lot of distributions

Separate file

Every packager uses his own GPG key to sign the pkg.tar.gz file. Each Arch installation needs an initial database with the GPG keys. Pacman downloads the pkg.tar.gz and checks the signature.

pacman internals

Package file format

  • .tar.xz by default, but some are .tar.gz. See this news article for further details. Extract with Template:Codeline
  • within the archive, the path to a file gives the path where it will be installed (relative to /); extracting a package to / installs it
  • there are two hidden files in the archive's / directory:
    • .INSTALL is an optional shell script that can define functions that are called after install, upgrade, or remove operations. It is placed in the same directory as the Template:Filename when building (e.g. Template:Filename and is defined inside the Template:Filename with Template:Codeline. It is stored in the local database after the package is installed
    • .PKGINFO is a text file with package metadata. It is generated using information in the Template:Filename. It is used to generate the desc file, which goes in the in the sync database
  • further information at Creating Packages

Links

Git branches

  1. Dans newgpg branch

Bug reports

  1. Bugreport Signed packages

Blogs

  1. Geoffrey carriers blog
  2. Attack on package managers
  3. Attack faq

Mailing list discussions and patches

  1. Add Keyring option in alpm/pacman
  2. Package signing again
  3. PATCH (newgpg) Let pacman specify GnuPG's home directory.
  4. Dan's pacman tree build&test
  5. GPG work
  6. GPG signature option in makepkg patch
  7. GPG signature support for makepkg
  8. GPG signature option in makepkg, adapted to Dan McGee's suggestions patch
  9. GPG verification patch
  10. GPGSIG in repo-add patch
  11. Signing by default
  12. Package Database signing
  13. Pointless to use non-md5 for makepkg INTEGRITY_CHECK
  14. Can we trust our mirrors
  15. Multiple/Shared Architectures

Forum discussions

  1. Pacman vulnerable to MITM attacks?
  2. Arch approach to security
  3. Pacman Veanurability
  4. Package signing
  5. pacman vulnerabilities