pkgbase repo signing infrastructure

Gordon Tetlow <[email protected]> Sat, 29 Nov 2025 22:54:14 -0800
Newsgroups	gmane.os.freebsd.architechture
Message-ID	<[email protected]>
TL;DR: FreeBSD 15.0 pkgbase repo signing keys are hosted on AWS KMS controlled by Release Engineering. Backup keys are held by the Security Officer.

(Much) Longer Version:
Speaking as the current serving Security Officer (successors welcome, apply within), I wanted to pull the veil back a bit on how the underlying Project infrastructure works for generating signed repos for pkgbase.

For FreeBSD 15.0, we are primarily relying on Amazon Web Services (AWS) Key Management Service (KMS) for signing the FreeBSD-base package repositories. The Release Engineering team headed by Colin Percival, who has extensive experience with AWS, built the AWS KMS infrastructure based on my suggestion and a proof of concept (POC) I pulled together to validate the approach. Colin took my initial POC, expanded upon it, and turned it into a production setup which he asked me to peer review. Those scripts are available here:
https://github.com/cperciva/pkgbase.freebsd.org

The AWS KMS keys were generated on the AWS KMS Hardware Security Modules (HSMs) and the private keys cannot be exported. This is industry best practice for signing infrastructure like this.

The SHA256 fingerprint of the PEM representation of AWS KMS RSA public key can be found in the tree here:
URL: https://cgit.freebsd.org/src/tree/share/keys/pkgbase-15/trusted/awskms-15?h=releng/15.0
SHA256: 1d7b45d20fa8d6ed26f9b4a13ac81a6b5df860b9fe644d07b87e92298ba72595

Now, we don’t want to put our eggs into a single basket, even a basket as generally robust as AWS KMS offering (I’m not concerned that they are going to lose the keys entirely). Additionally, this would lock us in to a single 3rd party provider. To avoid that, I generated a separate RSA key on an offline system and stored it in a GELI encrypted filesystem image on a set of redundant thumb drives. This is my standard way of generating secrets that the Security Officer and team have to manage. I have yet to get a copy of these to my deputy, that will happen in the future.

The SHA256 fingerprint of the PEM representation of the offline RSA public key can be found in the tree here:
URL: https://cgit.freebsd.org/src/tree/share/keys/pkgbase-15/trusted/backup-signing-15?h=releng/15.0
SHA256: 56a77bdcb6c3cf7984729c6138bd5617c24aa0d466b3b604c96205b2c5629f3c

I don’t intend to use these signing keys. They are strictly for recovery purposes in case of a catastrophe.

As we evolve this signing infrastructure, we will commit a signing key to the tree in a pre-activated state, meaning we have the key but are not yet using it, until we have sufficient time to distribute the key to clients. Only once all supported versions have a particular signing key will we then start using the new signing key.

Lastly, we are planning to have a distinct set of signing keys per major version, so the maximum timeframe of the 15.x keys would be until 2029.

Gordon
Hat: security-officer
signature.asc (application/pgp-signature, 512 B)