8000 Add support for validating signatures from PGP subkeys by drGrove · Pull Request #2874 · containers/image · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add support for validating signatures from PGP subkeys #2874

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

drGrove
Copy link
@drGrove drGrove commented Jun 22, 2025

This change should update the gpgme and openpgp implmenetations to support validating signatures made by signing subkeys. It will close an open issue that was referenced specifically in podman, but should resolve this across a number of tools that use this library.

This change should update the gpgme and openpgp implmenetations to
support validating signatures made by signing subkeys. It will close an
open issue that was referenced specifically in [podman](containers/podman#16406),
but should resolve this across a number of tools that use this library.

Signed-off-by: Danny Grove <danny@dannygrove.com>
@drGrove drGrove force-pushed the drgrove/fix-pgp-subkey-verification branch from 77893fc to f79e1b8 Compare June 22, 2025 22:38
Copy link
Collaborator
@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

containers/podman#16406 contains a long discussion about expired (or revoked) keys, IIRC it’s fairly unclear what is the right thing to do for long-term artifacts like software, and with no trusted timestamps.

Adding what, 150? new lines of code to the security critical signing code path is also a bit unattractive (although that’s, by itself, not at all a reason not to do the right thing).

There’s also a bit of awkward timing in that #2569 will probably replace the default / recommended verification implementation.

OTOH, these design concerns are, right now, also a topic there: #2569 (comment) .

@drGrove
Copy link
Author
drGrove commented Jun 23, 2025

There’s also a bit of awkward timing in that #2569 will probably replace the default / recommended verification implementation.

I noticed this as I was finishing out the implementation but based on my understanding of the comments. It appears the GPGPME/Go OpenPGP will still exist, it just won't be the hot path. As the sequoia OpenPGP implementation has also been something that's still being worked though, having any support for subkeys IMO is ideal.

containers/podman#16406 contains a long discussion about expired (or revoked) keys, IIRC it’s fairly unclear what is the right thing to do for long-term artifacts like software, and with no trusted timestamps.

To my understanding, once a key is revoked or expired the signature is no longer valid. Regardless of when it was signed. This default to close IMO is a feature. Revocations are packets within the key just like anything else and generally the systems/users doing validation of OpenPGP signatures understand the implications of this. If a key is revoked and pushed to a keyserver, the user/machine has to pull down the updated packets for it to take effect within the verification pipeline. If you are aware that a revocation has been published but you still need to use a previously signed image it would probably be more ideal for you to mirror the image and sign it yourself than the much less secure option of not importing the updated key. This same problem exists is most signing schemes (key rotation).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0