>Number: 2072 >Notify-List: [EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> 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= -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]