mutt/2072: Requires GPG_TTY to be set in order to accept
>Number: 2072
>Notify-List: 316388@xxxxxxxxxxxxxxx
>Category: mutt
>Synopsis: Requires GPG_TTY to be set in order to accept
>Confidential: no
>Severity: normal
>Priority: medium
>Responsible: mutt-dev
>State: open
>Keywords:
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Sep 18 22:05:10 +0200 2005
>Originator: Joey Hess
>Release:
>Organization:
>Environment:
>Description:
Hello,
this is about Debian Bug#316388, in which Joey Hess (CC'ed) argues
that Mutt should not be requiring GPG_TTY to be set in order to accept
using gnupg-agent. I think he has a point; I will now explain what I
understand the current situation is, and how I think it could be
improved.
> Marco d'Itri wrote:
> > On Jun 30, Joey Hess <joeyh@xxxxxxxxxx> wrote:
> > > gpg-agent 1.9.15-6 does not set a GPG_TTY variable. I tried setting
> > > this variable and mutt began using the agent properly.
> > I understand that this is a feature. Feel free to argue against it with
> > the upstream developers.
> current versions of gpg and pinentry work perfectly well, even
> at the console, without GPG_TTY being set. gpg falls back to using
> ttyname() and other methods to get the tty to pass to pinentry.
Yes, this paragraph is true. If you invoke gpg at the console without
GPG_TTY set, it'll figure out there's a tty involved and will tell
pinentry that; so it'll work.
However, this is not the case if it's Mutt who invokes gpg, since then
the stdin, stdout, and stderr of the gpg process will be pipes, and
gpg will not be able to figure out there's a tty involved; so it'll
fail.
Obviously, when in X11 and using pinentry-qt or pinentry-gtk, the
above does not apply.
So, we have that:
(a) either at the console, or in X11 but with gnupg-agent configured
to use pinentry-curses, it is _required_ that GPG_TTY is set for
gpg calls to succeed, and Mutt takes care of enforcing that.
(b) when in X11 with gnupg-agent configured to use a pinentry-x11,
GPG_TTY is not needed at all, yet Mutt does require it.
The current behavior of the code with respect to this is to just
always (*) require GPG_TTY to be set, but this is not documented at
all.
(*) Of course, it's impossible for Mutt to distinguish beteween (a)
and (b).
* * *
_If_ we accept Joey's point that Mutt has no business enforcing the
presence of GPG_TTY, since there are cases when it is not needed, I
see two possible solutions (with #2 being my prefered option, since it
just makes things work):
1. remove the check for GPG_TTY, and add to the documentation of
$pgp_use_gpg_agent that some pinentry agents will need it to
work. Attached gpg_tty.patch1 which does this.
2. remove the check for GPG_TTY, and make the pgp_use_gpg_agent
function add it to the environment if it's not present. Attached
gpg_tty.patch2 does this, which I'm considering adding to the
Debian package (though I'd welcome comments first).
>How-To-Repeat:
>Fix:
Unknown
>Add-To-Audit-Trail:
>Unformatted:
using gnupg-agent
----gnatsweb-attachment----
Content-Type: text/x-diff; name="gpg_tty.patch1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gpg_tty.patch1"
LS0tIHBncC5jfgorKysgcGdwLmMKQEAgLTEwNiw3ICsxMDYsNyBAQAogCiBpbnQgcGdwX3VzZV9n
cGdfYWdlbnQgKHZvaWQpCiB7Ci0gIHJldHVybiBvcHRpb24gKE9QVFVTRUdQR0FHRU5UKSAmJiBn
ZXRlbnYgKCJHUEdfVFRZIikgJiYgZ2V0ZW52ICgiR1BHX0FHRU5UX0lORk8iKTsKKyAgcmV0dXJu
IG9wdGlvbiAoT1BUVVNFR1BHQUdFTlQpICYmIGdldGVudiAoIkdQR19BR0VOVF9JTkZPIik7CiB9
CiAKIGNoYXIgKnBncF9rZXlpZChwZ3Bfa2V5X3QgaykKLS0tIGluaXQuaH4KKysrIGluaXQuaApA
QCAtMTQzNCw3ICsxNDM0LDkgQEAKICAgeyAicGdwX3VzZV9ncGdfYWdlbnQiLCBEVF9CT09MLCBS
X05PTkUsIE9QVFVTRUdQR0FHRU5ULCAwfSwKICAgLyoKICAgKiogLnBwCi0gICoqIElmIHNldCwg
bXV0dCB3aWxsIHVzZSBhIHBvc3NpYmx5LXJ1bm5pbmcgZ3BnLWFnZW50IHByb2Nlc3MuCisgICoq
IElmIHNldCwgbXV0dCB3aWxsIHVzZSBhIHBvc3NpYmx5LXJ1bm5pbmcgZ3BnLWFnZW50IHByb2Nl
c3MuIE5vdGUKKyAgKiogdGhhdCBzb21lIHBpbmVudHJ5IGFnZW50cywgbm90YWJseSBwaW5lbnRy
eS1jdXJzZXMsIHdpbGwgcmVxdWlyZQorICAqKiB0aGUgR1BHX1RUWSBlbnZpcm9ubWVudCB2YXJp
YWJsZSB0byBiZSBzZXQgaW4gb3JkZXIgdG8gYmUgZnVuY3Rpb25hbC4KICAgKiogKFBHUCBvbmx5
KQogICAqLwogICB7ICJwZ3BfdmVyaWZ5X3NpZyIsICAgRFRfU1lOLCAgUl9OT05FLCBVTCAiY3J5
cHRfdmVyaWZ5X3NpZyIsIDB9LAo=