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

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

−

== Problem Space ==

+

=== Problem Space ===

−

<!-- Describe the problem this proposal seeks to solve

+

−

-->

+

==== Compose Times ====

−

=== Compose Times ===

+

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

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 manually initiate a signing run of the packages to be composed

Line 11:

Line 10:

* Having to verify delta rpms to ensure they still match the signature of the packages being deltæd

* Having to verify delta rpms to ensure they still match the signature of the packages being deltæd

−

=== Trust ===

+

==== 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.

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.

Line 18:

Line 17:

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.

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 ===

+

==== 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.

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.

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 ==

+

=== Solution Overview ===

−

<!-- Describe in brief the solution proposed

+

−

-->

+

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.

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 ===

−

== Scope ==

+

−

<!-- Describe the scope of what all things will be effected by the proposal

+

−

-->

+

* Koji

* Koji

* Signing Server

* Signing Server

Line 37:

Line 31:

* Documentation

* Documentation

−

+

== Discussion Points ==

−

= Discussion Points =

+

−

<!-- Describe things which should be discussed regarding the proposal. Specifics that need narrowing down, or contentions parts of the proposal.

+

−

-->

+

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:

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 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.

+

* 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.

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.

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.

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.

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.