Difference between revisions of "DeveloperWiki:Package signing"

From ArchWiki
Jump to: navigation, search
(Allan's TODO list: no longer exists)
(32 intermediate revisions by 13 users not shown)
Line 1: Line 1:
[[Category:Package development (English)]]
+
[[Category:Package development]]
[[Category:Arch development (English)]]
+
[[Category:Pacman development]]
This page will act as a brain dump and collaborative design document for implementation of package signing in pacman.
+
[[Category:Security]]
 +
This page covers usage of package signing with [[pacman]], as well as being a brain dump and collaborative design document.  To set up package signing in pacman, see [[pacman-key]].
  
See also: [[Package Signing Proposal for Pacman]]
+
See also: [[DeveloperWiki:Package Signing Proposal for Pacman]]
  
=Currently implemented signing functionality in pacman and associated tools=
+
Pacman 4 uses [[GnuPG]] to implement package signing.
*{{Codeline|makepkg}} can sign a package
+
*{{Codeline|repo-add}} can add said signature to the database and sign the database
+
*{{Codeline|pacman-key}} exists for the sake of managing keys, but there is missing functionality
+
*{{Codeline|pacman}} can verify package signatures from repo databases, detached (.sig) package signatures, and signatures of the repos themselves (still some work to do)
+
  
=How Arch will implement package signing=
+
==Usage==
  
*Packages will be signed using {{Codeline|makepkg --sign}}. This creates a detached binary signature (.sig).
+
===Arch implementation===
*The signed package will be added to the repository, and a detached signature of the repository will be generated, using {{Codeline|repo-add --verify --sign}}. The command line options indicate that the signature of the old database will be verified, and that the new database will be signed. Independently of these options, {{Codeline|repo-add}} will detect the detached signature, convert it via base64 to ASCII, and add it to the repository.
+
*{{Codeline|pacman}} will download both the databases and the database signatures and verify the databases upon database sync and each time the database is opened. When a package is loaded, its signature will be checked whether that comes from a repo database or a standalone .sig file.
+
  
=Course of action=
+
*Packages are signed using {{Ic|makepkg --sign}}. This creates a detached binary signature (.sig).
==Requirements==
+
*The signed package is added to the repository database, and a detached signature of the repository database will be generated, using {{Ic|repo-add --verify --sign}}. The command line options indicate that the signature of the old database will be verified, and that the new database will be signed. Independently of these options, {{Ic|repo-add}} will detect the detached signature, convert it via base64 to ASCII, and add it to the repository database.
These are the changes that need to be made before Arch can implement package signing.
+
*{{Ic|pacman}} will download both the databases and the database signatures and verify the databases upon database sync and each time the database is opened. When a package is loaded, its signature will be checked whether that comes from a repo database or a standalone .sig file.
 +
*{{Ic|pacman-key}} exists for the sake of managing keys, but there is missing functionality
  
===arch-keyring package===
+
===Signature checking===
Some package will be created that contains all necessary keys for an Arch user to validate package signatures.
+
  
===Key Policy===
+
To prepare for checking signed packages, run the [[pacman-key]] command shown below, with root permissions. It generates a random key and a “keyring” in {{ic|/etc/pacman.d/gnupg/}}. You may need to move the mouse around to generate [[pacman-key#How_can_I_collect_entropy.3F|entropy]] for the key.
The [https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages DeveloperWiki page for key creation] must be finalized. Several developers and now Kerrick are working on this; feel free to contribute.
+
  
===Key creation, submission and verification===
+
# pacman-key --init
Solely the responsibility of the developers. [https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages/Packager_Keys This page] gives the current progress.
+
  
===Testing===
+
If this command is never run, pacman will abort saying “failed to commit transaction (invalid or corrupted package [PGP signature])” when it encounters packages signed with an unknown key.
pactests must be written for all signing functionality. This is a big issue; if you would like to contribute, this is a good place to do so.
+
 
 +
By default, pacman automatically accepts unsigned packages, but signed ones are rejected with an error unless pacman considers the key to be “trusted”. This corresponds to {{ic|1=SigLevel = Optional}} in pacman.conf; see [//www.archlinux.org/pacman/pacman.conf.5.html#_package_and_database_signature_checking Package and database signature checking] in the pacman.conf man page for further information.
 +
 
 +
Pacman usually prompts to add new keys of signed packages to its keyring. Keys can be manually compared against the lists of Arch [[developer]]s and [[Trusted Users|trusted users]] on the [https://www.archlinux.org Arch Linux web site]. If the ''SigLevel'' configuration specifies “TrustAll”, pacman considers keys to be trusted once they are imported to the keyring, so it will then continue installing each package. If pacman does not prompt to add new keys (cannot find on configured key server perhaps?), they could still be added manually by using the [[pacman-key]] tool.
 +
 
 +
If ''SigLevel'' specifies ''TrustedOnly'' (the default), pacman also considers the “trust level” for each key. A key is considered trusted if it is locally signed, or it has a sufficient level in the pacman web of trust. Locally signing a key (with {{ic|pacman-key --lsign}}) only really works after the key has already been imported.
 +
 
 +
If there is a long time and failure right after checking packages integrity, edit {{ic|/etc/pacman.d/gnupg/gpg.conf}} to use a different key server, for example {{ic|keyserver hkp://pgp.mit.edu}} instead of keys.gnupg.net.
 +
 
 +
==Course of action for development==
  
 
===Documentation===
 
===Documentation===
 
Documentation for the new features must be reviewed and finalized.
 
Documentation for the new features must be reviewed and finalized.
  
==Additional Features==
+
===Additional Features===
 
These are important but non-essential features that should be added soon after package signing is implemented. Work on these issues can start now, but priority should be given to the "requirements" above.
 
These are important but non-essential features that should be added soon after package signing is implemented. Work on these issues can start now, but priority should be given to the "requirements" above.
  
===Package validation without root privileges===
+
====Package validation without root privileges====
 
Currently, pacman's GnuPG home directory (aka gpgdir, typically /etc/pacman.d/gnupg/) must be locked in order to check a package's signature. Only root can perform this locking, so either locking must be disabled for read-only accesses, or the directory must be copied/linked to a writable location when a user is performing package verification.
 
Currently, pacman's GnuPG home directory (aka gpgdir, typically /etc/pacman.d/gnupg/) must be locked in order to check a package's signature. Only root can perform this locking, so either locking must be disabled for read-only accesses, or the directory must be copied/linked to a writable location when a user is performing package verification.
  
===Timeline for increasing security===
+
====Timeline for increasing security====
 
A timeline for transitioning between some unsigned packages and a fully-signed set of packages must be made. This is the responsibility of the developers.
 
A timeline for transitioning between some unsigned packages and a fully-signed set of packages must be made. This is the responsibility of the developers.
  
===Allan's TODO list===
+
==How signing is implemented in other distributions==
Allan has a TODO list with further needed features at [[User:Allan/Package Signing]].
+
 
+
=How signing is implemented in other distributions=
+
 
===Frugalware===
 
===Frugalware===
 
Frugalware uses a fork of pacman which implements package signing (verify)
 
Frugalware uses a fork of pacman which implements package signing (verify)
Line 73: Line 72:
  
 
===Gentoo===
 
===Gentoo===
===Redhat/Fedora/CentOS===
+
According to the Gentoo wiki, individual ebuilds are not signed.
 +
 
 +
===Red Hat/Fedora/CentOS===
 
* Signature type: GPG
 
* Signature type: GPG
 
* Stored: in the RPM
 
* Stored: in the RPM
Line 79: Line 80:
 
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 [http://www.rpm.org/wiki/DevelDocs/FileFormat file format specification for details].
 
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 [http://www.rpm.org/wiki/DevelDocs/FileFormat file format specification for details].
  
NB: packages built for the RedHat Network are signed with the [https://www.redhat.com/security/team/key/ RedHat official key(s)] but technically a RPM can be signed using any other key (one can even add another signature to the RPM)
+
NB: packages built for the Red Hat Network are signed with the [https://www.redhat.com/security/team/key/ Red Hat 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:
 
To check a package correction, one must first import the signer's key first:
Example for RedHat
+
Example for Red Hat:
 
  rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY
 
  rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY
  
Line 95: Line 96:
 
       MD5 sum: OK (4be23a341d23b794d08fbee35c459c83)
 
       MD5 sum: OK (4be23a341d23b794d08fbee35c459c83)
  
Option --nogpg prevents rpm from checking GPG signatures
+
Option {{ic|--nogpg}} prevents rpm from checking GPG signatures
  
 
==== Pros ====
 
==== Pros ====
Line 103: Line 104:
 
* Space greedy on repos
 
* Space greedy on repos
  
===Suse===
+
===SUSE===
 +
 
 
===Slackware===
 
===Slackware===
 
===Ubuntu===
 
===Ubuntu===
Line 113: Line 115:
 
* Space greedy (2 files for 1 package)
 
* Space greedy (2 files for 1 package)
  
=Links=
+
==Links==
 
===Bug reports===
 
===Bug reports===
# [http://bugs.archlinux.org/task/5331 Bugreport Signed packages]
+
# [https://bugs.archlinux.org/task/5331 Bugreport Signed packages]
  
 
===Blogs===
 
===Blogs===
Line 123: Line 125:
  
 
===Mailing list discussions and patches===
 
===Mailing list discussions and patches===
# [http://www.archlinux.org/pipermail/pacman-dev/2008-June/006607.html Add Keyring option in alpm/pacman]
+
# [https://www.archlinux.org/pipermail/pacman-dev/2008-June/006607.html Add Keyring option in alpm/pacman]
#[http://www.archlinux.org/pipermail/pacman-dev/2009-June/008858.html Package signing again]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2009-June/008858.html Package signing again]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-December/007808.html PATCH (newgpg) Let pacman specify GnuPG's home directory.]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-December/007808.html PATCH (newgpg) Let pacman specify GnuPG's home directory.]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-December/007726.html Dan's pacman tree build&test]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-December/007726.html Dan's pacman tree build&test]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-December/007761.html GPG work]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-December/007761.html GPG work]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-June/006548.html GPG signature option in makepkg patch]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-June/006548.html GPG signature option in makepkg patch]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-June/006560.html GPG signature support for makepkg]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-June/006560.html GPG signature support for makepkg]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-June/006552.html GPG signature option in makepkg, adapted to Dan McGee's suggestions patch]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-June/006552.html GPG signature option in makepkg, adapted to Dan McGee's suggestions patch]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-June/006559.html GPG verification patch]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-June/006559.html GPG verification patch]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-June/006559.html GPGSIG in repo-add patch]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-June/006559.html GPGSIG in repo-add patch]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-June/006621.html Signing by default]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-June/006621.html Signing by default]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-December/007720.html Package Database signing]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-December/007720.html Package Database signing]
#[http://www.archlinux.org/pipermail/arch-general/2009-January/003216.html Pointless to use non-md5 for makepkg INTEGRITY_CHECK]  
+
#[https://www.archlinux.org/pipermail/arch-general/2009-January/003216.html Pointless to use non-md5 for makepkg INTEGRITY_CHECK]  
#[http://www.archlinux.org/pipermail/arch-dev-public/2008-November/009089.html Can we trust our mirrors]
+
#[https://www.archlinux.org/pipermail/arch-dev-public/2008-November/009089.html Can we trust our mirrors]
#[http://www.archlinux.org/pipermail/pacman-dev/2008-September/007567.html Multiple/Shared Architectures]
+
#[https://www.archlinux.org/pipermail/pacman-dev/2008-September/007567.html Multiple/Shared Architectures]
 
===Forum discussions===
 
===Forum discussions===
#[http://bbs.archlinux.org/viewtopic.php?id=35609 Pacman vulnerable to MITM attacks?]
+
#[https://bbs.archlinux.org/viewtopic.php?id=35609 Pacman vulnerable to MITM attacks?]
#[http://bbs.archlinux.org/viewtopic.php?pid=333982#p333982 Arch approach to security]
+
#[https://bbs.archlinux.org/viewtopic.php?pid=333982#p333982 Arch approach to security]
#[http://bbs.archlinux.org/viewtopic.php?id=58302 Pacman Veanurability]
+
#[https://bbs.archlinux.org/viewtopic.php?id=58302 Pacman Veanurability]
#[http://bbs.archlinux.org/viewtopic.php?id=27867 Package signing]
+
#[https://bbs.archlinux.org/viewtopic.php?id=27867 Package signing]
#[http://bbs.archlinux.org/viewtopic.php?id=51570 pacman vulnerabilities]
+
#[https://bbs.archlinux.org/viewtopic.php?id=51570 pacman vulnerabilities]

Revision as of 06:32, 18 July 2013

This page covers usage of package signing with pacman, as well as being a brain dump and collaborative design document. To set up package signing in pacman, see pacman-key.

See also: DeveloperWiki:Package Signing Proposal for Pacman

Pacman 4 uses GnuPG to implement package signing.

Usage

Arch implementation

  • Packages are signed using makepkg --sign. This creates a detached binary signature (.sig).
  • The signed package is added to the repository database, and a detached signature of the repository database will be generated, using repo-add --verify --sign. The command line options indicate that the signature of the old database will be verified, and that the new database will be signed. Independently of these options, repo-add will detect the detached signature, convert it via base64 to ASCII, and add it to the repository database.
  • pacman will download both the databases and the database signatures and verify the databases upon database sync and each time the database is opened. When a package is loaded, its signature will be checked whether that comes from a repo database or a standalone .sig file.
  • pacman-key exists for the sake of managing keys, but there is missing functionality

Signature checking

To prepare for checking signed packages, run the pacman-key command shown below, with root permissions. It generates a random key and a “keyring” in /etc/pacman.d/gnupg/. You may need to move the mouse around to generate entropy for the key.

# pacman-key --init

If this command is never run, pacman will abort saying “failed to commit transaction (invalid or corrupted package [PGP signature])” when it encounters packages signed with an unknown key.

By default, pacman automatically accepts unsigned packages, but signed ones are rejected with an error unless pacman considers the key to be “trusted”. This corresponds to SigLevel = Optional in pacman.conf; see Package and database signature checking in the pacman.conf man page for further information.

Pacman usually prompts to add new keys of signed packages to its keyring. Keys can be manually compared against the lists of Arch developers and trusted users on the Arch Linux web site. If the SigLevel configuration specifies “TrustAll”, pacman considers keys to be trusted once they are imported to the keyring, so it will then continue installing each package. If pacman does not prompt to add new keys (cannot find on configured key server perhaps?), they could still be added manually by using the pacman-key tool.

If SigLevel specifies TrustedOnly (the default), pacman also considers the “trust level” for each key. A key is considered trusted if it is locally signed, or it has a sufficient level in the pacman web of trust. Locally signing a key (with pacman-key --lsign) only really works after the key has already been imported.

If there is a long time and failure right after checking packages integrity, edit /etc/pacman.d/gnupg/gpg.conf to use a different key server, for example keyserver hkp://pgp.mit.edu instead of keys.gnupg.net.

Course of action for development

Documentation

Documentation for the new features must be reviewed and finalized.

Additional Features

These are important but non-essential features that should be added soon after package signing is implemented. Work on these issues can start now, but priority should be given to the "requirements" above.

Package validation without root privileges

Currently, pacman's GnuPG home directory (aka gpgdir, typically /etc/pacman.d/gnupg/) must be locked in order to check a package's signature. Only root can perform this locking, so either locking must be disabled for read-only accesses, or the directory must be copied/linked to a writable location when a user is performing package verification.

Timeline for increasing security

A timeline for transitioning between some unsigned packages and a fully-signed set of packages must be made. This is the responsibility of the developers.

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

According to the Gentoo wiki, individual ebuilds are not signed.

Red Hat/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 Red Hat Network are signed with the Red Hat 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 Red Hat:

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)

Links

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