-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sign rpm repo metadata #9027
Merged
Merged
Sign rpm repo metadata #9027
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wadells
requested review from
webvictim and
russjones
and removed request for
webvictim
November 17, 2021 02:58
webvictim
approved these changes
Nov 17, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, although it's been a while since I edited Drone YAMLs in anger...
wadells
force-pushed
the
walt/rpm-sign
branch
from
November 18, 2021 01:00
aace90e
to
20b9177
Compare
tcsc
approved these changes
Nov 25, 2021
russjones
approved these changes
Dec 1, 2021
wadells
force-pushed
the
walt/rpm-sign
branch
from
December 18, 2021 17:40
1dcceba
to
567cb6d
Compare
wadells
force-pushed
the
walt/rpm-sign
branch
from
December 20, 2021 05:39
567cb6d
to
0b90dd7
Compare
tcsc
approved these changes
Dec 20, 2021
webvictim
approved these changes
Dec 22, 2021
This was referenced Jan 4, 2022
This helps support zypper on Suse, and improves our general RPM distribution security posture. The threat model is someone compromises AWS, but not our signing keys. In this case, they could update repo metatdata to point to an unsigned package. With metadata signed, this is no longer possible -- both the index and the package are verified. For more info on this change, see this very helpful blog post: https://blog.packagecloud.io/eng/2014/11/24/howto-gpg-sign-verify-rpm-packages-yum-repositories/
The force push/new commit was to resolve a conflict with the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: Do not merge until the backports are ready. We need all branches that publish RPMs to sign, lest we have an old branch regenerate metadata, invalidating a signature from a newer branch.
Also, as of 2021-12-19, the testing for this PR is now complete.
Summary
This PR introduces signing for RPM repo metadata in addition to the RPMs themselves.
This helps support
zypper
on Suse (#6445), and improves our general RPMdistribution security posture. The threat model is someone compromises
AWS, but not our signing keys. In this case, they could update repo
metatdata to point to an unsigned package. With metadata signed, this
is no longer possible -- both the index and the package are verified by
the various yum clients.
For more info on this change, see this very helpful blog post:
https://blog.packagecloud.io/eng/2014/11/24/howto-gpg-sign-verify-rpm-packages-yum-repositories/
Contributes to #6445.
Testing Done
In progress. I've tested this workflow with the following dockerfiles, but I've not tested the Drone implementation yet.
I removed the S3 upload for deb, rpm, and regular artifacts from the publishing job in a private branch. I then pushed
v9.0.0-dev.1
and tried a publish to make sure everything runs to completion. Good thing too, as I caught a couple failures related to gpg 2.0 vs gpg 2.2. See the final, successful test run here:https://drone.teleport.dev/gravitational/teleport/9603/1/9