Koji Build Autosign Proposal

Overview

Automatically sign non-scratch builds as they happen in Koji with a gpg key.

Problem Space

Compose Times

By manually signing packages with different keys for different releases we increase the amount of time it takes to compose due to

• Having to manually initiate a signing run of the packages to be composed
• Having to verify that the packages being pulled from koji match the signature for the repo being composed
• Having to verify delta rpms to ensure they still match the signature of the packages being deltæd

Trust

Currently only packages in updates, updates-testing, the release tree, and sometimes rawhide are signed. Consumers of packages directly from koji have no easy way to verify that the package they are consuming was actually built using Fedora's Koji build system.

Because we have unsigned packages in rawhide, we are unable to force gpgcheck=1 in yum configs, which would protect users from consuming packages outside of Fedora that are not properly signed.

Currently by using multiple keys, a false sense of "Trust" to the quality of the packages has been assumed by the user. This assumption is incorrect.

Signature Changes

When we change the gpg signature on packages it introduces a change to the rpm file without a change to the epoch:name-version-release of the package. Some systems don't handle this very well. It also prevents us from being able to use hardlinks between builds of packages that have not changed from release to release.

By using multiple signatures for packages, we have to store written out copies of the signed packages in the koji store, duplicating a lot of package data for a tiny change in the header of a package, or we have to enable our compose tools to have authority to write out signed versions of the packages they wish to access at compose time, increasing risk in our compose tools to do damage and increasing time necessary to do composes.

Solution Overview

As non-scratch builds complete in Koji, an automated tool will gpg sign and write out on the koji store a signed version of that build. A single gpg key will be used to sign all the builds. This key will indicate that the package came from Fedora (koji) and has not been tampered with since.

Scope

• Koji
• Signing Server
• package manager configurations
• Documentation

Discussion Points

We need to discuss the proper way to stage builds before they are signed, to ensure that no builds go out to users before they have been signed. We could:

• Adjust make build to do a --skip-tag build, and only apply the tag after the package has been signed.
• Adjust the build targets to tag into a -candidate like tag and only move to a dist-??? tag once the build has been signed.

We need to balance the desire to reduce churn and complexity of having multiple keys with the potential for one key compromise to compromise all the packages for ever.

Owner

Jesse Keating