Using gpg/pgp signatures in Package Managers

[s243a]

Intro

In debian repositories one way of verifying the content of the package is with a cryptographic hash. For a given repo there is usually a file that contains metadata for all the packages in the repo such as the package name, version and in the case of the debian repo usually the sha256 cryptographic hash.

Here are some examples of said metadata:
https://deb.torproject.org/torproject.o ... 6/Packages
http://ftp.nluug.nl/os/Linux/distr/pupp ... l-official
http://slackware.cs.utah.edu/pub/slackw ... CKAGES.TXT
http://slackware.cs.utah.edu/pub/slackw ... CKSUMS.md5

In both the cases of the debian repo and the slackware repo the metadata is a series of property lists. These properties contain information such as the package name and version. In the case of the debian repo, the metadata contains both the md5sum hash and the sha256 hash. In some cases it even contains the sha1hash.

In the slackware repo there is a separate metadata file for the md5hash. Unfortunately a sha256 hash isn't provided despite md5 being considers a weak cryptography hash by today's standards. In both the slackware and the debian repo the metadata is signed with a pgp signature.

The signing process authenticates the cryptography hashes contained in the above metadata files. In a puppylinux repo the metadata is in tabular format, no cryptographic hashes are provided in the metadata and the metadata is not signed with pgp signature. Furthermore, the repositories don't even use https. There is a md5hash provided in the .pet packages as part of the petspecs but there is no pgp signature for the metadata in the pet packages.

In short in the puppylinux repositories there is no security provided to verify the integrity of the downloads (not counting checks for data corruption)! One could rectify this by providing their own signed list of cryptographic hashes for puppy packages, like the slackware repo's do with the md5 hashes:
http://slackware.cs.utah.edu/pub/slackw ... CKSUMS.md5

alternatively using repos with https would help to protect from man in the middle attacks when using the package manager but only if the package manager actually checks the https certificate and doesn't use the --no-check-certificate option in wget.


What I've done so far

In my fork of Scotmann's package manager (i.e. pkg), I've added the ability to check sha256 hashes and provided some related code for md5 hashes. I haven't yet added code to check the pgp signature of the repo metadata.

https://gitlab.com/sc0ttj/Pkg/issues/75#note_248920683

How to check the pgp signatures in the package manager

The pgp signature contains an encrypted hash of the data. The public key is used to decrypt the hash and the decrypted hash in the signature can be used used to verify the file. Usually, the public key is provided as part of a certificate [1]:

Certificate formats
A digital certificate is basically a collection of identifying information bound together with a public key and signed by a trusted third party to prove its authenticity. A digital certificate can be one of a number of different formats.

PGP recognizes two different certificate formats:

PGP certificates
X.509 certificates

https://users.ece.cmu.edu/~adrian/630-f ... intro.html

However, in the case of the tor repo the public key is provided without any additional metadata:
https://deb.torproject.org/torproject.o ... 6DDD89.asc
but this is likely because one is expected to download the certificate elsewhere and only use the public key in the repo as a way of knowing which public key to use in order to decrypt the signature files.

In the slackware repo the full certificate is provide:
http://slackware.cs.utah.edu/pub/slackw ... .2/GPG-KEY


Public keys can also be found in keyrings[1].

For example, suppose your key ring contains Alice's key. You have validated Alice's key and you indicate this by signing it. You know that Alice is a real stickler for validating others' keys. You therefore assign her key with Complete trust. This makes Alice a Certification Authority. If Alice signs another's key, it appears as Valid on your keyring.

https://users.ece.cmu.edu/~adrian/630-f ... intro.html

You can validate a pgp signature based on the web of trust for a particular keyring. For instance, you could use the devuan-keyring as the basis for validating a signature. In which cases we only accept public keys for verification purposes if they are in the keyring or the public key of a person sufficiently trusted by members of the keyring (see web of trust). Whether or not these third parties are used is based on the web of trus tmodel. In the example above we see that assigning someone complete trust makes them a certificate authority for the key ring.

Keyrings, can also be downloaded vida the package manager. For instance:

Code: Select all

# pkg --search keyring | awk -F ' ' '{print $1}' | grep keyring
debian-archive-keyring
debian-keyring
debian-ports-archive-keyring
devuan-keyring
emdebian-archive-keyring
gambas3-gb-desktop-gnome-keyring
gir1.2-gnomekeyring-1.0
gnome-keyring
keyringer
leap-archive-keyring
libgnome-keyring-common
libgnome-keyring-dev
libgnome-keyring0-dbg
libgnome-keyring0
libgnome-keyring1.0-cil-dev
libgnome-keyring1.0-cil
libpam-gnome-keyring
mercurial-keyring
monodoc-gnome-keyring-manual
neurodebian-archive-keyring
pidgin-gnome-keyring-dbg
pidgin-gnome-keyring
pkg-mozilla-archive-keyring
python-gnomekeyring
python-keyring
python-keyrings.alt
python3-keyring
python3-keyrings.alt
ubuntu-archive-keyring

Another way to find public keys is via keyservers[1].

Certificate servers
A certificate server, also calledacert server or a key server, is a database that allows users to submit and retrieve digital certificates. A cert server usually provides some administrative features that enable a company to maintain its security policies — for example, allowing only those keys that meet certain requirements to be stored.

https://users.ece.cmu.edu/~adrian/630-f ... intro.html

For instance you can find the keyring of the torbowser team with the command [2]:

Code: Select all

gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@torproject.org

On debian keyrings are typically stored at [3]:

Code: Select all

/usr/share/keyrings/

and this folder should only be writable by root. On debian in the /etc/apt/sources.list file you can specify which keyring to use in order to verify the package metadata. For example [3]:

Code: Select all

deb [signed-by=/usr/share/keyrings/deriv-archive-keyring.gpg] https://deriv.example.net/debian/ stable main

Scotmann's package manager (i.e. pkg) but doesn't yet support adding brackets for options like this yet. We could rectify this by first parssing out these options, exporting their values and then pass the modified line to ppa2pup. Another way to add third party repos in debian type systems is to use the deb822 format [2][4]. The deb822 format is a bit cleaner when providing options.


Notes
1 - https://users.ece.cmu.edu/~adrian/630-f ... intro.html
2 - https://support.torproject.org/tbb/how- ... signature/
3 - https://wiki.debian.org/DebianRepository/UseThirdParty
4 - https://manpages.debian.org/buster/apt/ ... RAL_FORMAT