Gopass: Doesn't work out of the box with CentOS

[Zamiell]

Steps to reproduce:

1) Install a fresh CentOS 7 VM (server minimal)
2) yum install -y wget git
3) wget https://github.com/justwatchcom/gopass/releases/download/v1.4.0-rc1/gopass-1.4.0-rc1-linux-amd64.rpm
4) rpm -i gopass-1.4.0-rc1-linux-amd64.rpm
5) gpg --gen-key (all defaults, making a passphrase)
6) gopass init (all defaults)
7) gopass insert asdf (works)
8) gopass asdf (fails)

You need a passphrase to unlock the secret key for
user: "Zamiell <[email protected]>"
4096-bit RSA key, ID F1E992A1, created 2017-09-25 (main key ID 0DA8C3E9)


Error: failed to retrieve secret 'asdf': Failed to decrypt
exit status 11

The problem seems to be that it never prompts me for my passphrase. It presumably fails because its trying to use a blank passphrase.

The same problem occurs when:

• Using v1.4.0 rc1 from: https://github.com/justwatchcom/gopass/releases/download/v1.4.0-rc1/gopass-1.4.0-rc1-linux-amd64.rpm
• Using v1.3.2 from: https://github.com/justwatchcom/gopass/releases/download/v1.3.2/gopass-1.3.2-linux-amd64.rpm
• Doing a go get and running from source with: go run main.go asdf

[Zamiell]

Further information:

[root@localhost gopass]# gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://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: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Could be related to GPG version?

[Zamiell]

I tried gopass out on Ubuntu 16.04 and it seems to work fine out of the box.

Interestingly,

zamiell@ubuntu:~$ gpg --version
gpg (GnuPG) 1.4.20
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://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: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

[Zamiell]

Well, I found a workaround.

On CentOS, when I manually do a gpg --decrypt ~/.password-store/asdf.gpg >/dev/null, it successfully prompts me for my passphrase, and then I enter it. Now, the passphrase is cached from the gpg-agent, and I can use gopass normally... at least until the passphrase expires from the cache, upon which I have to redo this process. Yuck.

[Zamiell]

This also happens on Fedora 17, and its even worse, because by default the gpg-agent doesn't seem to be caching passwords.

[dominikschulz]

Thank you very much for reporting this. The interaction between gpg and gpg-agent is unfortunately complex. We try to reproduce this. It may be an issue with gopass, but I rather suspect a gpg configuration issue right now (which we should document).

[dragon788]

@Zamiell can you try with gpp2 on Fedora and Ubuntu? I realize you got it working on Ubuntu, but it would be good to keep the gpg version the same to ensure there isn't some other issue at play.

[Zamiell]

Looks like with the recent git refactoring in recent versions, it "works" on CentOS now, sort of.

I opened six new issues today relating to the gopass "out of the box" experience. Once they are resolved, I will give this another thorough test from the beginning on a fresh CentOS 7 VM and report back any findings.

[samzilverberg]

I've suffered the same problem on mac and i'm able to reproduce it like so:

• start from clean:
  
  
  
  • no gpg2, no gopass, no gpg keys,
  
  
  • delete ~/.password-store and ~/.config/gopass
  
  
• install all deps via brew: gpg2, gopass 1.6.2
• setup a new gpg key gpg --full-gen-key with 5 years validity and a password
• init gopass pass store: gopass init --no-git
• store some dummy secret gopass insert bla -m using vi
• get decrypt error via: gopass bla

it seems to be directly related to not prompting for the password.
the workaround from zamiell seems to work.
doing gpg --decrypt ~/.password-store/bla.gpg will prompt for password.
after putting it in, gopass is able to decrypt secrets.

[samzilverberg]

@dominikschulz , confused emoji? dya need more info? or having probs reproducing?
or i'm just reading the emoji wrong? 😄

[dominikschulz]

I still don't know how to approach this issue. I have experience suprious "failed to decrypt" issues myself, but never in a reproducible manner.

[samzilverberg]

i've tried to reproduce it in multiple ways, and the only reliable way i found is the one i describe before, which is starting from clean and setting up a new password protected key and new pass store.

here's the full stack track when using the GOPASS_DEBUG flag:

GOPASS_DEBUG=true gopass show mypass
[DEBUG] Loaded config: &{Root:0xc42000f4a0 Mounts:map[] Version:1.5.1 XXX:map[]}
[DEBUG] Loaded config from /Users/myuser/.config/gopass/config.yml: &{Root:0xc42000f4a0 Mounts:map[] Version:1.5.1 XXX:map[]}
[DEBUG] gpg.Decrypt: /usr/local/bin/gpg [/usr/local/bin/gpg --quiet --yes --compress-algo=none --no-encrypt-to --no-auto-check-trustdb --decrypt /Users/myser/pathto/mypass.gpg]
[DEBUG] Stacktrace: Failed to decrypt
github.com/justwatchcom/gopass/store.init
    /private/tmp/gopass-20171025-14324-1353tq9/gopass-1.5.1/src/github.com/justwatchcom/gopass/store/err.go:13
github.com/justwatchcom/gopass/store/sub.init
    <autogenerated>:1
github.com/justwatchcom/gopass/config.init
    <autogenerated>:1
github.com/justwatchcom/gopass/action.init
    <autogenerated>:1
... some more not helpful stuff

I imagine its a prob in the gpg usage, executing the cmd but not being able to handle the password prompt.

I'm not a golang developer, so Its hard for me to try out a fix, what I imagine tryind would be:

1. trying to remove some of those flags such as "quiet" and "yes", maybe then it will prompt for password.
2. if cant get prompt to show, then still play with flags and inspect output of the command to see if can recognize that a password should be input, and then:
3. workaround described in https://unix.stackexchange.com/questions/60213/gpg-asks-for-password-even-with-passphrase and https://astera.zendesk.com/hc/en-us/community/posts/115000231383-How-to-pass-the-passphrase-into-GPG-for-decryption
   basically the workaround is prompting for pass yourself, then echo+piping it into the gpg command so it automatically puts it in the prompt it show.

[dragon788]

There is a gpg config flag for the pinentry-program that can trigger a graphical prompt instead of hanging/failing if it tries to use a tty/curses interface, and on platforms like macOS it is often recommended to use pinentry-mac in order to get a graphical prompt rather than one inline in the terminal like pinentry-curses does by default.

Perhaps there is a missing dependency on CentOS/Fedora where they don't "prescribe" a pin entry technique/package for the user resulting in a failure while Ubuntu/Debian packagers for gpg have chosen to suggest/recommend pinentry-curses or one of the other alternatives as a default?

Do you have pinentry-* installed when encountering this issue on CentOS/Fedora/RHEL? On Ubuntu you can check if it was installed with dpkg --get-selections | grep pinentry and examine the gnupg/gnupg2/gnupg-agent packages for dependencies with apt show gnupg-agent.

[Vlli]

@samzilverberg
The only working fix i found, was to uninstall the new gnupg (2.x) and install the old gnupg (1.4) version with brew:

brew uninstall gnupg --ignore-dependencies
brew install [email protected] (Add it to the PATH by hand)

Then in works like a charm.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cloudbring]

I am still having this issue this week. I'm using Centos 7 and cannot get the decryption to work.

[dominikschulz]

@cloudbring Thanks for the ping. We'll keep this open and try to take look at that.

[j3mdamas]

Hi,

Since I've started using gopass as a password manager for DevOps projects and I am using CentOS 7, I thought I should come here and give my feedback. Installing gopass 1.8.6 using:

curl -L https://github.com/gopasspw/gopass/releases/download/v1.8.6/{gopass-1.8.6-linux-amd64.rpm} -o "#1"
rpm -i gopass-1.8.6-linux-amd64.rpm

and after fighting a bit with GPG and gpg-agent (maybe something like https://help.github.com/en/articles/telling-git-about-your-signing-key could be in the instructions?), encryption/decryption works for me. Here are some details on the Os as well:

[vagrant@localhost ~]$ uname -a
Linux localhost.localdomain 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[vagrant@localhost ~]$ cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)

Cheers

[j3mdamas]

Actually, I was able to reproduce the issue. For me at least, it was due to a poorly set GPG_TTY environment variable, which means there is no password prompt and the decryption fails automatically.

Do export GPG_TTY=$(tty) and it will be solved (assuming you're suing to another user)

[dominikschulz]

I think we covered the GPG_TTY issue already.