Closed fmpwizard closed 3 years ago
On the Helm project: (https://github.com/helm/helm/issues/2843) I think they @technosophos found a potential cause. There is a new keyring format for gnupg 2.1: https://gnupg.org/faq/whats-new-in-2.1.html#keybox
Following up here, I was getting this error due to using ReadKeyRing when I should have been using ReadArmoredKeyRing. The key format has changed though, so it may be that as well.
I don't think @jmataa and I have the same issue, while the error is the same, from my sample code, the error you get would be at:
entityList, err = openpgp.ReadKeyRing(keyringFileBuffer)
but in my case it is at
d, err := openpgp.ReadMessage(file, entityList, nil, nil)
And note that using the same code and key I can decrypt many other files just fine, but this one vendor sends me these files that cause issues. But I'm still getting into the details of the pgp format so maybe I'm missing something
@FiloSottile I found the problem!
a keyring can be in two formats, binary or armored, and we have two functions to read each, ReadKeyRing
and ReadArmoredKeyRing
The pgp file we get from this one company, is also armored, where all the previous files from other companies we have been getting were in binary format.
But, we don't have a ReadArmoredMessage
function.
Right now I create a bufio.Reader
and Peek
into the file to see if it starts with --
(could prob make it read more to see if I get a full -----BEGIN PGP MESSAGE-----
) , and if I do, I call openpgp/armor.Decode
and then call openpgp.ReadMessage
This works for our use case and maybe you would want to close this ticket, but, would you be ok accepting a CL that:
ReadArmoredMessage
and a bit of code comment to ReadMessage
pointing out you may want to look at the *Armored*
version?
orReadMessage
or some other better solution ?Thanks.
It also took some hours (!) for me to figure out, I have to export the secret key to the old format..
Why not have ReadKeyRing
handle both binary or armored key rings at the same time? Really should not be up to application developers to have to test the raw keyring.
Why not have
ReadKeyRing
handle both binary or armored key rings at the same time? Really should not be up to application developers to have to test the raw keyring.
+1
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.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
We use this function to decrypt files we get from different companies, only files from one company fail, all others decrypt fine.
What did you expect to see?
No error and a decrypted zip file, which is what the command line gpg does
What did you see instead?
the error:
tag byte does not have MSB set
More details.
I brought this up on the mailing list https://groups.google.com/d/topic/golang-nuts/-bBXt-0nVT4/discussion
but I'll paste more details here:
Part of the verbose output from gpg when it decrypts it is: