New answers tagged gpg
pass uses gnupg2, which does not share it's keyring with gnupg 1.x. Import your keys again using gnupg2 instead of gnupg. If you already have your keys in gnupg on the target machine run: $ gpg --export-secret-keys > keyfile $ gpg2 --import keyfile After importing, you may need to update the trust on your key. You should see a Secret key is available. ...
With the same indications, if anyone stumbles across this issue, the solution may be bit different. Your pass is using gpg2 instead of gpg, you might have used to generate/manage your keys (or, vice-versa). Verify with: bash -x $(which pass) insert foo
This turned out to be a bug in the version of python that this issue of Ubuntu was installing.
Looking at the versions reveals the problem: % gpg-agent --version gpg-agent (GnuPG) 2.1.7 % gpg --version gpg (GnuPG) 1.4.19 The components come from different packages (gnupg2-2.1.7-1.fc22.x86_64 and gnupg-1.4.19-2.fc22.x86_64 in my case). The solution is to use the gpg2 command instead of ...
The layout of the --edit-key listing is not documented (not that I could find anyway). The abbreviations you mention however are, somewhere. I searched for S: and found that I actually wanted to search for usage:. In "GPG Key related Options": 4.2.1 How to change the configuration These options are used to change the configuration and are usually ...
Use apt-cdrom or setup /etc/apt/sources.list manually.
Apparently enigmail developers deliberately decided to not support this possibility. A workaround is to manually modifying the file pref.js adding the exclamation mark after the key id specified in lines like user_pref("mail.identity.id1.pgpkeyId", "0x089380E4!"); This has to be done once for every configured identity. EDIT I discovered a problem with ...
My preferred method is to just disable the stupid history expansion feature you never heard of and never wanted and will likely never use even though you now know about it: $ echo "hello!" bash: !": event not found $ set +o histexpand $ echo "hello!" hello!
Piping data into ssh (like you did) is the right way of passing input data to a command executed via SSH. The issue here is that gpg needs two input streams to read from: one (STDIN) to read the data to be encrypted, another one (the interactive terminal /dev/tty) to read the passphrase (which is why you need to pass the -t option to ssh). If you ...
Top 50 recent answers are included