opening a pgp encrypted msg with mutt, using the example gpgrc file for configuration, fails to prompt for a passphrase. This worked until recently.
It appears that gpg --batch and --passphrase-fd no longer work together.
I have not yet been able to isolate what exactly changed. gpg and gpg2 have been updated recently though; currently gpg 1.4.22 (pkg gnupg) and gpg2 1.84.
Ugh, my mistake; gpg (gpg1) has not been updated recently. One of its dependencies has been; devel/readline to 8.0.
Same for me.
Add the following to your muttrc file:
Hey, that works. Thanks!
This page claims that this should be set:
In my experience, mutt always behaves better when gnupg is abstracted through gpgme. All my mutt<->gpg troubles went away when I used gpgme.
Is this a FreeBSD-specific problem you're seeing, or is this with gpg in general? I always run the full gnupg test suite before updating, so I suspect that what you're seeing may be changed behaviour.
Yes, this was changed behavior. In the 1.12.0 release pgp_use_gpg_agent was changed to be set by default.
I would also agree that using gpgme (on by default in the port) in mutt makes pgp significantly easy since it's a single config option "set crypt_use_gpgme" and you don't have to worry about gpg1 vs gpg2 or command line option changes.
I tried crypt_use_gpgme just now; it does not work for me. fails with the error "Could not decrypt PGP message" then "Could not copy message". It never prompts for a passphrase.
This is using the package Muttrc with the option enabled.
What are the chances you're running this inside of a jail where you're entering the jail with something like 'ezjail-admin console ...' or 'jexec jail sh' ?
I'm able to at least get the same issue you're having with mutt + gpgme inside a jail that's from a tty. It seems there's something going with pinentry and jexec'ing into a jail. If I ssh to the jail everything works as expected.
I don't know enough about the differences between ssh'ing and jexe'ing into a jail from a tty point of view to know what the real issue is.
Also, something worth noting is that it's recommended, at least with mutt, to use pinentry-curses since it doesn't support pinentry-tty (the default pinentry - I'd really like to see curses be the default). You can do this via an option change of pinentry or adding 'pinentry-program /usr/local/bin/pinentry-curses' in ~/.gnupg/gpg-agent.conf assuming you install pinentry-curses.
I inherited gnupg with pinentry-tty as the default. Is there a downside to using pinentry-curses as the default? I use pinentry-curses on all my machines.
None that I know of. Both tty and curses have the same dependencies. So at most it would just be a UI shock for users. Also, all other pinentry packages (centos6/7/debian) are curses by default.
FYI the tty issues with mutt are discussed here https://marc.info/?t=155165949900001&r=1&w=2
I would expect the same issue to be true for any other curses based application that tries to use pinentry via pinentry-tty that didn't get the exit/entering of curses just right.
Adding Jason to this bug. Would you consider making pinentry-curses the default instead of pinentry-tty? As Derek noted, -curses is the default for a number of other OSes, including OpenBSD.
Thanks for the comments, Derek.
I am not using a jail of any manner.
I do have pinentry linked to pinentry-tty. I tried it with curses, which made no difference in behavior.
Is there gpg-agent running before or after you attempt to open the message in mutt?
What does ~/.gnupg/gpg-agent.conf look like? If there is an agent running can you kill the gpg-agent (gpgconf --kill gpg-agent) before you try to open the message that should prompt you for a key password?
Can you provide the output of 'mutt -v' and 'pkg info mutt gnupg gpgme' when gpgme is enabled?