Bug 234095

Summary: mail/mutt and mail/neomutt mail client can only decrypt with GPG1 but pkg only requires GPG2 as dependency
Product: Ports & Packages Reporter: bugcatcher <autosend>
Component: Individual Port(s)Assignee: Baptiste Daroussin <bapt>
Status: New ---    
Severity: Affects Many People CC: dereks, riggs, w.schwarzenfeld
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   

Description bugcatcher 2018-12-17 12:50:46 UTC
Scenario: FreeBSD 12.0 release, just installed

Essentially, Mutt/Neomutt throws simple error messages, such as 'Could not copy message', when trying to decrypt a message in a mailbox, with only GPG2 installed.

As soon as 'gnupg1' package is installed, it is able to decrypt messages.

Unfortunately pkg required gpg2 as a dependency, which can create a confusing situation.

It took quite a while to solve this bug.
Firstly because the line "source /usr/share/doc/mutt/examples/gpg.rc" must be in muttrc, unlike Linux, for decryption to work.
Secondly because only Neomutt is compiled with debug options, whereas Mutt is compiled without debug options (but it does make sense, to keep one simple and one complex, as long as both are available). But once you have debug options enabled you can add verbose flags to modified GPG calls in your muttrc, and then get more fine grained understanding of the issue.
Comment 1 Derek Schrock 2018-12-18 02:30:56 UTC
Is there any reason you're not using gpgme with crypt_use_gpgme in your rc.  It's pretty much a single line config that replaces everything from gpg.rc.
Comment 2 Derek Schrock 2018-12-23 17:36:33 UTC
I'd still highly recommend using crypt_use_gpgme instead however.

Since gnupg 2.1 '--pinentry-mode loopback' is required when using --passphrase-fd.  Can you add this and see if it fixes your issue?

Either upstream needs so add this to contrib/gpg.rc to commands that use --passphrase-fd, or we need to patch it in at build time.

There are still some supported distros that install gnugp 2.0 so having upstream fix this might not be best until gnupg 2.1 is default.
Comment 3 bugcatcher 2019-02-06 13:22:20 UTC
Unfortunately I tried your suggestions but neither work, both continue to throw the "could not decrypt PGP message" and "could not copy message" error.

After reverting to the working config as mentioned in my original post, it only throws the above error messages when the GPG password input is wrong.
Comment 4 Thomas Zander freebsd_committer 2019-02-24 07:39:02 UTC
(In reply to Derek Schrock from comment #2)

This seems specific to our builds. All documentation I found on this topic says it should work when using --pinentry-mode loopback and adding allow-loopback-pinentry to ~/.gnupg/gpg-agent.conf

Still, on FreeBSD, we just get 'Could not copy message'...
Comment 5 Derek Schrock 2019-03-03 08:05:06 UTC
(In reply to Thomas Zander from comment #4)

adding allow-loopback-pinentry to ~/.gnupg/gpg-agent.conf shouldn't be necessary.

I can say that adding "--pinentry-mode loopback" to the gpg.rc example does work.
Keep in mind there are multiple gpg commands in that file are you updating pgp_decrypt_command?  You'll still want "--pinentry-mode loopback" on the others but pgp_decrypt_command is the one that's needed at least for this PR.

I can also confirm crypt_use_gpgme works as well with one exception is that when using pinentry-tty (default for security/pinentry) you need to hit control-j to send the password.   This appears to be a regression from here  https://mutt-users.mutt.narkive.com/Ygk07kZN/mutt-1-5-23-9-gnupg-2-1-6  including the mangling of returns from the forked output.  However, it still works.  I've always used pinentry-curses.

I have tested the above with my own poudriere builds, FreeBSD's latest and quarterly repos.  Both gpg.rc with additions and gpgme work.

If you're still having issues it would be best to focus on gpgme since that's the highly recommended setting from myself and upstream.
Comment 6 Derek Schrock 2019-03-03 08:18:20 UTC
(In reply to bugcatcher from comment #3)

Can you attach 'mutt -v' output?
Comment 7 Derek Schrock 2019-03-03 22:18:02 UTC
Keep in mind I'm only accounting for mail/mutt here.  It seems neomutt with the brief testing I've seen or have asked other to perform it is possible neomutt has its own set of problems.