Skip to content
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

x/crypto/openpgp: fails to handle expired subkeys correctly #15353

Closed
abarisani opened this issue Apr 18, 2016 · 2 comments
Closed

x/crypto/openpgp: fails to handle expired subkeys correctly #15353

abarisani opened this issue Apr 18, 2016 · 2 comments
Milestone

Comments

@abarisani
Copy link

@abarisani abarisani commented Apr 18, 2016

Hello,

importing OpenPGP keys with expired signature subkeys, but a valid non-expired signature subkey, is not being handled correctly by golang.org/x/crypto/openpgp functions such as ReadEntity.

What I am experiencing is that when the imported public key has a single non-expired signature subkey then there are no issues.

However if the imported key has one or more expired signature subkeys, and a valid one as the last packet, only the first expired subkey is considered when creating the PublicKey object, making it invalid for encryption.

I am attaching a public key that exhibits these properties, the key was parsed as follows:

keyBlock, _ := armor.Decode(keyFile)
reader := packet.NewReader(keyBlock.Body)
entity, _ := openpgp.ReadEntity(reader)

and later used with openpgp.Encrypt().

Currently gpg --export, even with --export-options export-minimal, always carry expired signature subkeys (despite gpg documentation suggesting the contrary). This means that I have no easy way of exporting the public key in a way which is friendly to golang.org/x/crypto/openpgp, unless I am missing something.

Let me know if you need further information to debug this.

Thanks!

test_key.txt

@abarisani abarisani changed the title golang.org/x/crypto/openpgp fails to handle expired subkeys correctly x/crypto/openpgp fails to handle expired subkeys correctly Apr 18, 2016
@bradfitz bradfitz changed the title x/crypto/openpgp fails to handle expired subkeys correctly x/crypto/openpgp: fails to handle expired subkeys correctly Apr 18, 2016
@bradfitz bradfitz added this to the Unreleased milestone Apr 18, 2016
abarisani added a commit to f-secure-foundry/interlock that referenced this issue Apr 20, 2016
abarisani added a commit to f-secure-foundry/interlock that referenced this issue Jun 8, 2016
@fawkesley
Copy link

@fawkesley fawkesley commented Sep 13, 2018

I also have this problem as my key contains multiple subkey binding signatures, but only the first (expired) one is processed. Later packets are ignored, so entity.Subkeys[...].Sig.KeyExpired(time.Now()) are always true

Thanks so much @abarisani for your workaround

This very recent commit (which fixed #26449) nearly fixed this but not quite.

In a follow-up patch, we can improve this further by keeping the
most recent signature, as suggested by RFC4880:

An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but it
is RECOMMENDED that priority be given to the most recent self-
signature.

I've written and tested a patch on our fork which is working for us.

Regarding GnuPG, yes export-minimal,export-clean should strip older signatures, and this is apparently fixed as of 2.2.9

@FiloSottile
Copy link
Contributor

@FiloSottile FiloSottile commented Mar 29, 2021

Per the accepted #44226 proposal and due to lack of maintenance, the golang.org/x/crypto/openpgp package is now frozen and deprecated. No new changes will be accepted except for security fixes. The package will not be removed.

If this is a security issue, please email security@golang.org and we will assess it and provide a fix.

If you're looking for alternatives, consider the crypto/ed25519 package for simple signatures, golang.org/x/mod/sumdb/note for inline signatures, or filippo.io/age for encryption. You can read a summary of OpenPGP issues and alternatives here.

If you are required to interoperate with OpenPGP systems and need a maintained package, we suggest considering one of multiple community forks of golang.org/x/crypto/openpgp. We don't endorse any specific one.

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

Successfully merging a pull request may close this issue.

None yet
4 participants