This page will act as a brain dump and collaborative design document for implementation of package signing in pacman.
- 1 Aim
- 2 Why sign packages?
- 3 How signing is implemented in other distributions
- 4 Ideas
- 5 Implementation details
- 6 Links
Implement package signing in pacman.
Why sign packages?
Because it could lessen the possibility of installing malicious packages potentially dangerous for the system and data.
How signing is implemented in other distributions
Frugalware uses a fork of pacman which implements package signing (verify)
Arch based distro gnuffy uses signed packages with their custom package manager Spaceman modeled on pacman.
Binary packages (.deb)
To sum up, the GPG signature is included in the .deb.
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")
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.
- 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
- Enable Official Distribution package signature but also enables personal and multiple signatures
- Implies complicated package format with header containing signature of an inner tarball (not very KISS)
- Space greedy on repos
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
- Space greedy (2 files for 1 package)
SSL key chain
Seems to be the solution used by a lot of distributions
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.
Mailing list discussions and patches
- Add Keyring option in alpm/pacman
- Package signing again
- PATCH (newgpg) Let pacman specify GnuPG's home directory.
- Dan's pacman tree build&test
- GPG work
- GPG signature option in makepkg patch
- GPG signature support for makepkg
- GPG signature option in makepkg, adapted to Dan McGee's suggestions patch
- GPG verification patch
- GPGSIG in repo-add patch
- Signing by default
- Package Database signing
- Pointless to use non-md5 for makepkg INTEGRITY_CHECK
- Can we trust our mirrors
- Multiple/Shared Architectures