Support for gpg2?

[jc00ke]

Hi!

I'm using gpg 2.1 and I'm unable to use sops because it can't find the new pubring.kbx that gpg2 uses. Looks like it's hardcoded to open pubring.gpg.

After digging a bit more, I'm not sure crypto/openpgp supports gpg > 2 :frowning:

I'm guessing I can't use sops unless I have secring.gpg and pubring.gpg and not pubring.kbx?

[jvehent]

We need to add an option to use command line gpg or gpg2 instead of using the crypto/openpgp library. I haven't looked at gpg2 yet. Do you know if the command line arguments are the same as with gpg ?

[autrilla]

I think we should do this distinctly from the openpgp Go package. Maybe even replace the current gpg handling to use the gpg binary like python sops did, and add openpgp as a new master key provider (like KMS). This way we'd end up with 3 providers, KMS, go-openpgp and gpg.

On Fri, Jan 13, 2017, 15:54 Julien Vehent [:ulfr] notifications@github.com wrote:

We need to add an option to use command line gpg or gpg2 instead of using the crypto/openpgp library. I haven't looked at gpg2 yet. Do you know if the command line arguments are the same as with gpg ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mozilla/sops/issues/189#issuecomment-272461629, or mute the thread https://github.com/notifications/unsubscribe-auth/ACJ-V5w4VgRjdji4IpxVlNF4mrNX3Zo7ks5rR5AwgaJpZM4LiYBw .

[jvehent]

That doesn't make a lot of sense to me. It's the same protocol and key format, just a different way of accessing the data.

[jvehent]

sops 1 supported SOPS_GPG_EXEC. I think sops 2 should support it as well and, if defined, use the gpg binary specified in path to encrypt/decrypt the data key.

[autrilla]

It has the benefit of allowing to use sops without gpg installed. I don't know if that is important to anyone, though. Since we already have an implementation using crypto/openpgp, I think it might be good to keep it around and add a new one using the binary.

On Fri, Jan 13, 2017, 16:25 Julien Vehent [:ulfr] notifications@github.com wrote:

That doesn't make a lot of sense to me. It's the same protocol and key format, just a different way of accessing the data.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/mozilla/sops/issues/189#issuecomment-272469163, or mute the thread https://github.com/notifications/unsubscribe-auth/ACJ-V-d6eP5RuyyvfO1FWVEywJqijPfLks5rR5dXgaJpZM4LiYBw .

[jvehent]

I absolutely think crypto/openpgp should be the default method of performing PGP operations. My point is users should be able to override this and use the gpg1/2 binary by specifying the path to the binary in SOPS_GPG_EXEC.

[jimmycuadra]

Are we sure the Go package doesn't already support the GnuPG 2.1 keyring location and format? The problem I saw from looking at the code was that sops has the paths of the keyrings hardcoded to the <= 2.0 versions of GnuPG, not necessarily a problem with the OpenPGP implementation itself.

[jc00ke]

I don't see support for anything over v2.0 in the read tests.

[jvehent]

I'm 99.8% sure crypto/openpgp doesn't support gpg2 keyring format. That said, you can change the default location of the keyring using the GNUPGHOME env variable.

[jimmycuadra]

My understanding is that secring.gpg is gone, as well. Both rings are stored inside pubring.kbx.

[jc00ke]

@jimmycuadra is correct, see the changelog

Maybe we can access it through the agent?

With GnuPG 2.1 this changed and gpg now also delegates all private key operations to the gpg-agent.

[lvh]

Hang on; doesn't SOPS talk to gpg-agent? (This is relevant to my interests, because I was unable to get SOPS to work with my Yubikey 4 token.)

[autrilla]

@lvh the Python version did, as it just calls the gpg binary it finds in your PATH. The Go version uses Go's crypto/openpgp package, which is fully independent from GPG and thus doesn't talk to the agent.

[lvh]

Gotcha. See #191; I was confused by: https://github.com/mozilla/sops/blob/0483f8a07af035f2cb75e7a72b1901eccac82ed1/pgp/keysource.go#L15

also hi @autrilla long time no see

[autrilla]

Err, you're right, we do talk to gpg-agent. I didn't express myself correctly.

SOPS talks to gpg-agent to retrieve the passphrase for private keys. crypto/openpgp does not support smart card private keys. In any case, as I understand it, the way we communicate with gpg-agent would not work for smart cards at all, as even if we get the passphrase we'll never have access to the private key, which crypto/openpgp needs.

It's very likely I'm totally wrong about this, as my understanding of gpg is very limited.

[lvh]

OK, that makes a lot of sense after more review of the code! You're right of course, the entire point of the token is that the key lives on the card and never, never leaves -- you send the message to the token to be encrypted, and it sends the encrypted thing back to you.

[jimmycuadra]

I'm glad I learned the Go version doesn't support smart cards. I've been using sops with my Yubikey for a while and only now am realizing it's cause I still have the Python version. I'd better not upgrade. >_<

[jvehent-sops-ci]

Sops 1 is still maintained and installable via pip. You're safe to upgrade, we won't force you to v2.

On January 18, 2017 8:08:30 PM EST, Jimmy Cuadra notifications@github.com wrote:

I'm glad I learned the Go version doesn't support smart cards. I've been using sops with my Yubikey for a while and only now am realizing it's cause I still have the Python version. I'd better not upgrade. >_<

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/mozilla/sops/issues/189#issuecomment-273652292

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[yingzong]

jvehent commented on Jan 13 I absolutely think crypto/openpgp should be the default method of performing PGP operations. My point is users should be able to override this and use the gpg1/2 binary by specifying the path to the binary in SOPS_GPG_EXEC.

Au contraire, given that crypto/openpgp isn't updated -- and tbh, even if it is -- it should only be a backup to CLI gpg when the latter isn't installed. What's the path forward on this issue?

[autrilla]

The path forward for now is implementing support for calling the gpg binary. What we should default to is a bit bikesheddy but I suppose it's up for discussion.

As I see it, the advantages for defaulting to crypto/openpgp:

• Simpler to implement, therefore harder to mess up
• No external dependencies

And the advantages for defaulting to the binary:

• Support for more gpg features such as smart cards and the new gpg2 keyring format

Personally I agree with @jvehent that defaulting to crypto/openpgp is the way to go here, even if it has some issues. In any case, we could just add an option in .sops.yaml to override the default.

[jvehent]

Regardless of which method we use, we should try the other method automatically on failure.

[autrilla]

This has been fixed by #238

[jubel-han]

Problems still in there with the latest version 3.0

$ sops example.yaml
... ...
Group 0: FAILED
    - | could not decrypt data key with PGP key:
      | golang.org/x/crypto/openpgp error: Could not load secring:
      | open /Users/xxx/.gnupg/secring.gpg: no such file or
      | directory; GPG binary error: exit status 2
... ...

$ sops --version
sops 3.0.0 (latest)
$ gpg --version
gpg (GnuPG) 2.2.1
libgcrypt 1.8.1
... ...

[autrilla]

Well, the GPG binary is exiting with status code 2, which is unsuccessful. This usually happens when GPG doesn't have access to the key, but it could be another cause. I suggest looking at https://github.com/mozilla/sops/blob/master/pgp/keysource.go#L60-L83 and executing the equivalent manually to see why GPG is erroring.

[chroto]

I'm seeing the same issue as @jubel-han

    - | could not decrypt data key with PGP key:
      | golang.org/x/crypto/openpgp error: Could not load secring:
      | open /Users/blergh/.gnupg/secring.gpg: no such file or
      | directory; GPG binary error: exit status 2

$ gpg --version
gpg (GnuPG) 2.2.1
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /Users/blergh/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

$ sops --version
sops 3.0.2 (latest)

[chroto]

@autrilla I'm having an issue with Decryption. not Encryption

so i guess it's this code? https://github.com/mozilla/sops/blob/master/pgp/keysource.go#L180-L195 .

I haven't looked deeply into this code in a while..

[autrilla]

Yes, that's it. Put the contents of "enc" for each of the GPG keys encrypting your file in a separate file and try decrypting that with GPG.

[chroto]

FWIW I tried running gpg manually as I understand the code is executing the command and it decrypted the data key just fine.

gpg --use-agent -d data_key.enc

[chroto]

@autrilla hmmm it's working now via sops. I must have been pointing to an old version in the Terminal I was testing in. Sorry for the distraction.

and btw thanks for responding so quickly 👍

[autrilla]

No problem! Glad it's working.

[benlangfeld]

@chroto I'm actually having the same problem, and it doesn't resolve itself. I'm a little lost at this point.

[autrilla]

Perhaps see #304 too?

[habnabit]

fwiw, I had the same issue using a smartcard without gpg-agent. once I unlocked the smartcard via gpg -d I was able to use sops successfully.

[autrilla]

@habnabit that's interesting... I guess maybe GPG tries and detect if it's running in a TTY and has different behavior? Because otherwise, all SOPS does is call gpg -d. I don't have a smart card with PGP support to test with, is there any chance you could try to run gpg -d without a TTY?

[lvh]

(Also relevant whenever someone describes their experience here: when you say gpg what is gpg --version because e.g. Homebrew will install gpg2 and call it gpg but on Linux in almost all cases gpg is gpg1 and gpg2 is gpg2 :))

You may want:

export GPG_AGENT_INFO="$(gpgconf --list-dirs agent-socket):0:1" 

... specifically if you're using a gpg2 gpg-agent but gpg1 to talk to it. (They're still compatible but gpg wants that env var and gpg2 doesn't so gpg2's gpg-agent stopped setting it at some point.)

[zak905]

I also experienced the same issue importing a key from a server to another. None of the above solutions worked for me. The issue was due to importing a public key without it's corresponding private key, so I had to:

gpg --export -a KEYID > pub.key
gpg --export-secret-keys -a KEYID > private.key

and then import both:

gpg --import pub.key
gpg --import private.key

This fixed the issue for me.

[slava-nikulin]

so why is this closed? the problem is still exists

[klausi]

A working solution was generated by Perplexity AI for me:

Export keys to old format: You can export your public keys to the old format:

gpg --export > ~/.gnupg/pubring.gpg

Then the SOPS decryption worked.