use apt::keyring to install the Jenkins APT repo key in Debian #1130
Conversation
zen-fu
force-pushed
the
apt-keyring
branch
2 times, most recently
from
b5f3bec to
0065613
Compare
kenyon
left a comment
kenyon
left a comment
There was a problem hiding this comment.
Not sure the key fingerprint check really adds any value, since if it's the wrong key, apt will complain when doing apt update, right?
Checking the fingerprint mitigates potential issues with compromised TLS CA, which could allow a MITM to provide a fake key to authenticate a fake package downloaded from a fake APT repo. (Conversely, if we don't verify the key, we rely completely on the TLS CA for authentication.) On the other hand, looks like neither So it's a choice between security (avoid relying solely on the TLS CA for package authentication) vs maintainability (having to update the fingerprint when it's updated upstream). If we're not verifying the fingerprint, then i think it doesn't make sense to keep it around in the code as it's not used and might give the wrong impression. Let me know if you prefer and i can remove it. |
|
My concern is that apt key verification functionality doesn't really belong in this module, it belongs in puppetlabs-apt. Unfortunately it seems like Perforce has given up on maintaining their modules. |
|
The point of @kenyon is right, this verification belongs to the apt module so that all consumers can benefit from it. If Perforce fail at maintaining these modules, I guess that at the point we are currently, we can just fork them and start to ship puppet-apt. Maybe something to discuss at the next vox meetup? |
Verifying the APT key fingerprint should really be a responsibility of
the `puppetlabs-apt` module, so we deliberately choose to not do it
here.
Note that, currenlty, neither the (obsolete) `apt::key` nor the
`apt::keyring` resources do key fingerprint verification, so this change
isn't really a regression. Here's an upstream issue:
puppetlabs/puppetlabs-apt#1175
Before this change, the key fingerprint was only used (by `apt::key`) to
name the file where the key was stored. Because no verification is made
either here or on the `puppetlabs-apt` side, we also remove the
`$gpg_key_id` class param. This change avoids the need to maintain the
hardcoded fingerprint, while also avoiding a false impression that they
fingerprint is somehow verified.
Discussion: voxpupuli#1130
|
i just pushed a commit that removes fingerprint verification and the key id param: 59ba0a9 FTR, here's a corresponding upstream issue: puppetlabs/puppetlabs-apt#1175 Let me know in case more changes are needed. :-) |
3 participants
Pull Request (PR) description
apt-key is not present in Debian Trixie, and because of that the
apt::keyresource doesn't work in that release. Upstream puppetlabs-apt advises:We also implement a check for the expected fingerprint, as that's not done by the upstream code (even though it probably should support that?). This way, we will at least get an error in Puppet if the fingerprint doesn't match.
This Pull Request (PR) fixes the following issues
Fixes #1129