Bug 239381 - security/gnupg does not prompt for passphrase within mutt
Summary: security/gnupg does not prompt for passphrase within mutt
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Adam Weinberger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-22 18:01 UTC by heas
Modified: 2019-07-30 22:32 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description heas 2019-07-22 18:01:10 UTC
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.
Comment 1 heas 2019-07-22 18:06:03 UTC
Ugh, my mistake; gpg (gpg1) has not been updated recently.  One of its dependencies has been; devel/readline to 8.0.
Comment 2 Thierry Thomas freebsd_committer 2019-07-22 18:27:48 UTC
Same for me.
Comment 3 Derek Schrock 2019-07-23 01:51:04 UTC
Add the following to your muttrc file:

   unset pgp_use_gpg_agent
Comment 4 heas 2019-07-23 16:25:33 UTC
Hey, that works.  Thanks!

This page claims that this should be set:
https://gitlab.com/muttmua/mutt/wikis/MuttGuide/UseGPG
Comment 5 Adam Weinberger freebsd_committer 2019-07-24 02:23:18 UTC
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.
Comment 6 Derek Schrock 2019-07-24 10:51:33 UTC
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.
Comment 7 heas 2019-07-24 23:18:39 UTC
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.
Comment 8 Derek Schrock 2019-07-25 23:00:46 UTC
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.
Comment 9 Adam Weinberger freebsd_committer 2019-07-29 14:12:25 UTC
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.
Comment 10 Derek Schrock 2019-07-29 20:52:43 UTC
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.
Comment 11 Adam Weinberger freebsd_committer 2019-07-29 22:13:39 UTC
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.
Comment 12 heas 2019-07-30 21:34:58 UTC
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.
Comment 13 Derek Schrock 2019-07-30 22:32:36 UTC
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?