* bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt @ 2013-09-29 9:22 Ted Zlatanov 2013-09-29 15:07 ` Thierry Volpiatto ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Ted Zlatanov @ 2013-09-29 9:22 UTC (permalink / raw) To: emacs-devel; +Cc: Daiki Ueno It used to be possible to do GPG_AGENT_INFO=none gpg --decrypt foo.gpg GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg etc. but with GPG 2.x that seems to be disabled and the pinentry prompt pops up no matter what. Without waiting for changes on the GPG side, the only option seems to be to downgrade to GPG 1.x, which is not a great solution. I haven't found a configuration option to disable the popup, and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't work: % unset GPG_AGENT_INFO % gpg --batch --decrypt authinfo.gpg gpg: CAST5 encrypted data gpg-agent[28496]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[28496]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: encrypted with 1 passphrase gpg: decryption failed: No secret key The effect to Emacs users is that the pinentry passphrase dialog comes up over and over, at least in X. It makes working with .gpg files (in VCS in particular) practically unusable and I haven't found a way to disable the pinentry prompt. I want to request either some workaroung or changes in epg.el or the ability to use another encryption backend besides GPG, e.g. http://ccrypt.sourceforge.net/ I am not opening a bug because it's not really a bug on our side IIUC. Any advice is welcome... I hope I missed something in the GPG2 docs! Thanks Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-29 9:22 bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt Ted Zlatanov @ 2013-09-29 15:07 ` Thierry Volpiatto 2013-09-29 17:48 ` Ted Zlatanov 2013-09-29 15:24 ` Daiki Ueno 2013-09-30 18:53 ` Stefan Monnier 2 siblings, 1 reply; 26+ messages in thread From: Thierry Volpiatto @ 2013-09-29 15:07 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > but with GPG 2.x that seems to be disabled and the pinentry prompt pops > up no matter what. Without waiting for changes on the GPG side, the > only option seems to be to downgrade to GPG 1.x, which is not a great > solution. I haven't found a configuration option to disable the popup, > and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't > work: Did you try to uninstall gnupg-agent packet? (It is a separate packet on debian based distro e.g ubuntu) BTW I have no problems with pinentry prompt. -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-29 15:07 ` Thierry Volpiatto @ 2013-09-29 17:48 ` Ted Zlatanov 0 siblings, 0 replies; 26+ messages in thread From: Ted Zlatanov @ 2013-09-29 17:48 UTC (permalink / raw) To: emacs-devel On Sun, 29 Sep 2013 17:07:02 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: TV> Ted Zlatanov <tzz@lifelogs.com> writes: >> but with GPG 2.x that seems to be disabled and the pinentry prompt pops >> up no matter what. Without waiting for changes on the GPG side, the >> only option seems to be to downgrade to GPG 1.x, which is not a great >> solution. I haven't found a configuration option to disable the popup, >> and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't >> work: TV> Did you try to uninstall gnupg-agent packet? TV> (It is a separate packet on debian based distro e.g ubuntu) TV> BTW I have no problems with pinentry prompt. If you look at my example, I disable the GPG agent. It's not the problem. Disabling pinentry doesn't work either. Make sure you're using GnuPG 2.x (I tested with 2.0.20). Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-29 9:22 bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt Ted Zlatanov 2013-09-29 15:07 ` Thierry Volpiatto @ 2013-09-29 15:24 ` Daiki Ueno 2013-09-29 17:57 ` Ted Zlatanov 2013-09-30 18:53 ` Stefan Monnier 2 siblings, 1 reply; 26+ messages in thread From: Daiki Ueno @ 2013-09-29 15:24 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > It used to be possible to do > > GPG_AGENT_INFO=none gpg --decrypt foo.gpg > GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg > etc. > > but with GPG 2.x that seems to be disabled and the pinentry prompt pops > up no matter what. Without waiting for changes on the GPG side, the > only option seems to be to downgrade to GPG 1.x, which is not a great > solution. I haven't found a configuration option to disable the popup, > and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't > work: Nowadays, GnuPG 2.1 or later has --pinentry-mode option, which provides a way to bypass the graphical pinentry prompt, like: $ gpg --batch --decrypt --pinetry-mode=loopback authinfo.gpg which just behaves like gpg1. I added the support to epg.el (see epg-pinentry-mode) some time ago, but not yet added any user option in epa.el. Patches (and testing) are welcome. Regards, -- Daiki Ueno ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-29 15:24 ` Daiki Ueno @ 2013-09-29 17:57 ` Ted Zlatanov 2013-10-02 7:23 ` Daiki Ueno 0 siblings, 1 reply; 26+ messages in thread From: Ted Zlatanov @ 2013-09-29 17:57 UTC (permalink / raw) To: emacs-devel On Sun, 29 Sep 2013 11:24:56 -0400 Daiki Ueno <ueno@gnu.org> wrote: DU> Ted Zlatanov <tzz@lifelogs.com> writes: >> It used to be possible to do >> >> GPG_AGENT_INFO=none gpg --decrypt foo.gpg >> GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg >> etc. >> >> but with GPG 2.x that seems to be disabled and the pinentry prompt pops >> up no matter what. Without waiting for changes on the GPG side, the >> only option seems to be to downgrade to GPG 1.x, which is not a great >> solution. I haven't found a configuration option to disable the popup, >> and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't >> work: DU> Nowadays, GnuPG 2.1 or later has --pinentry-mode option, which provides DU> a way to bypass the graphical pinentry prompt, like: DU> $ gpg --batch --decrypt --pinetry-mode=loopback authinfo.gpg DU> which just behaves like gpg1. I added the support to epg.el (see DU> epg-pinentry-mode) some time ago, but not yet added any user option in DU> epa.el. DU> Patches (and testing) are welcome. I'd love to test and patch, but the latest GnuPG release is 2.0.21 and I can't find mentions of 2.1 on their website. 2.0.20 doesn't have the --pinentry-mode option by default (tested in Gentoo). I assume this is the relevant commit that introduces it: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=21feecd48f990b2569cb4b385dea3e57b9501525 It seems that GnuPG has to be explicitly compiled with --allow-loopback-pinentry which IMO is a really painful requirement to pass onto Emacs users. I am surprised by this, but perhaps I've misunderstood something? Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-29 17:57 ` Ted Zlatanov @ 2013-10-02 7:23 ` Daiki Ueno 2013-10-02 10:34 ` Ted Zlatanov 0 siblings, 1 reply; 26+ messages in thread From: Daiki Ueno @ 2013-10-02 7:23 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > It seems that GnuPG has to be explicitly compiled with > --allow-loopback-pinentry which IMO is a really painful requirement to > pass onto Emacs users. I am surprised by this, but perhaps I've > misunderstood something? Why don't you ask Werner directly about the ideas behind this, instead of complaining here and seeking for a workaround? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-02 7:23 ` Daiki Ueno @ 2013-10-02 10:34 ` Ted Zlatanov 2013-10-02 12:48 ` Daiki Ueno 0 siblings, 1 reply; 26+ messages in thread From: Ted Zlatanov @ 2013-10-02 10:34 UTC (permalink / raw) To: emacs-devel On Wed, 02 Oct 2013 16:23:27 +0900 Daiki Ueno <ueno@gnu.org> wrote: DU> Ted Zlatanov <tzz@lifelogs.com> writes: >> It seems that GnuPG has to be explicitly compiled with >> --allow-loopback-pinentry which IMO is a really painful requirement to >> pass onto Emacs users. I am surprised by this, but perhaps I've >> misunderstood something? DU> Why don't you ask Werner directly about the ideas behind this, instead DU> of complaining here and seeking for a workaround? Because the bug or misbehavior is specifically in epg.el and I don't know the best way to fix it. If you're suggesting I should start fixing epg.el bugs and tracking GnuPG development, that's a different request I won't be able to fulfill. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-02 10:34 ` Ted Zlatanov @ 2013-10-02 12:48 ` Daiki Ueno 2013-10-02 13:27 ` Andrey Kotlarski 2013-10-02 13:38 ` Ted Zlatanov 0 siblings, 2 replies; 26+ messages in thread From: Daiki Ueno @ 2013-10-02 12:48 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > On Wed, 02 Oct 2013 16:23:27 +0900 Daiki Ueno <ueno@gnu.org> wrote: > > DU> Ted Zlatanov <tzz@lifelogs.com> writes: >>> It seems that GnuPG has to be explicitly compiled with >>> --allow-loopback-pinentry which IMO is a really painful requirement to >>> pass onto Emacs users. I am surprised by this, but perhaps I've >>> misunderstood something? > > DU> Why don't you ask Werner directly about the ideas behind this, instead > DU> of complaining here and seeking for a workaround? > > Because the bug or misbehavior is specifically in epg.el and I don't > know the best way to fix it. Well, I didn't mean to attack you. I guess the configure option is disabled by default because it apparently has a security risk and there are not so many users of that feature. If you could provide a use case, that might help convince him to make --allow-loopback-pinentry enabled by default (and release 2.2 and/or backport it to 2.0). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-02 12:48 ` Daiki Ueno @ 2013-10-02 13:27 ` Andrey Kotlarski 2013-10-02 13:38 ` Ted Zlatanov 1 sibling, 0 replies; 26+ messages in thread From: Andrey Kotlarski @ 2013-10-02 13:27 UTC (permalink / raw) To: emacs-devel [ 2 октомври 2013, 15:48 +0300, сряда ] Daiki Ueno: >... > I guess the configure option is disabled by default because it > apparently has a security risk and there are not so many users of that > feature. If you could provide a use case, that might help convince him > to make --allow-loopback-pinentry enabled by default (and release 2.2 > and/or backport it to 2.0). Another vote against this pinentry prompt - makes epg.el unusable on headless servers, emacs happily freezes on opening .gpg file. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-02 12:48 ` Daiki Ueno 2013-10-02 13:27 ` Andrey Kotlarski @ 2013-10-02 13:38 ` Ted Zlatanov 2013-10-03 1:52 ` Daiki Ueno 1 sibling, 1 reply; 26+ messages in thread From: Ted Zlatanov @ 2013-10-02 13:38 UTC (permalink / raw) To: emacs-devel On Wed, 02 Oct 2013 21:48:19 +0900 Daiki Ueno <ueno@gnu.org> wrote: DU> Ted Zlatanov <tzz@lifelogs.com> writes: >> On Wed, 02 Oct 2013 16:23:27 +0900 Daiki Ueno <ueno@gnu.org> wrote: >> DU> Ted Zlatanov <tzz@lifelogs.com> writes: >>>> It seems that GnuPG has to be explicitly compiled with >>>> --allow-loopback-pinentry which IMO is a really painful requirement to >>>> pass onto Emacs users. I am surprised by this, but perhaps I've >>>> misunderstood something? >> DU> Why don't you ask Werner directly about the ideas behind this, instead DU> of complaining here and seeking for a workaround? >> >> Because the bug or misbehavior is specifically in epg.el and I don't >> know the best way to fix it. DU> Well, I didn't mean to attack you. OK, I didn't take it that way :) DU> I guess the configure option is disabled by default because it DU> apparently has a security risk and there are not so many users of that DU> feature. If you could provide a use case, that might help convince him DU> to make --allow-loopback-pinentry enabled by default (and release 2.2 DU> and/or backport it to 2.0). See my earlier e-mails. But my bigger concern is that for many users, a new GnuPG release is years in the future, so even if you justify this change, it won't help anyone quickly. IMHO epg.el should work around this "feature" now with the --batch --passphrase-fd options that I mentioned, especially if they can work on all GnuPG versions (I haven't tested that). My question now, since we understand the problem well, is if you agree with this plan, and if so, do you need patches from me or other contributors, or will you address it yourself? There's no urgency implied here; I am simply trying to fix this for our users by the next Emacs release. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-02 13:38 ` Ted Zlatanov @ 2013-10-03 1:52 ` Daiki Ueno 2013-10-03 13:59 ` Ted Zlatanov 0 siblings, 1 reply; 26+ messages in thread From: Daiki Ueno @ 2013-10-03 1:52 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > See my earlier e-mails. But my bigger concern is that for many users, a > new GnuPG release is years in the future, so even if you justify this > change, it won't help anyone quickly. IMHO epg.el should work around > this "feature" now with the --batch --passphrase-fd options that I > mentioned, especially if they can work on all GnuPG versions (I haven't > tested that). Well, that's a design decision not to use --batch here (and probably in GPGME). If it used --batch, epg.el would need to know a passphrase even if it is not needed (for example, it is already cached in gpg-agent, encrypted with empty passphrase, etc.) And also it would inhibit gpg from doing other user queries until the gpg command terminates. > My question now, since we understand the problem well, is if you agree > with this plan, and if so, do you need patches from me or other > contributors, or will you address it yourself? There's no urgency > implied here; I am simply trying to fix this for our users by the next > Emacs release. Please don't. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-03 1:52 ` Daiki Ueno @ 2013-10-03 13:59 ` Ted Zlatanov 2013-10-03 14:59 ` Stefan Monnier 2013-10-04 0:12 ` Daiki Ueno 0 siblings, 2 replies; 26+ messages in thread From: Ted Zlatanov @ 2013-10-03 13:59 UTC (permalink / raw) To: emacs-devel On Thu, 03 Oct 2013 10:52:46 +0900 Daiki Ueno <ueno@gnu.org> wrote: DU> Ted Zlatanov <tzz@lifelogs.com> writes: >> See my earlier e-mails. But my bigger concern is that for many users, a >> new GnuPG release is years in the future, so even if you justify this >> change, it won't help anyone quickly. IMHO epg.el should work around >> this "feature" now with the --batch --passphrase-fd options that I >> mentioned, especially if they can work on all GnuPG versions (I haven't >> tested that). DU> Well, that's a design decision not to use --batch here (and probably in DU> GPGME). If it used --batch, epg.el would need to know a passphrase even DU> if it is not needed (for example, it is already cached in gpg-agent, DU> encrypted with empty passphrase, etc.) And also it would inhibit gpg DU> from doing other user queries until the gpg command terminates. OK, so there's no way to avoid the broken behavior in epg.el and any fixes on the GnuPG side have to wait until a new release (and someone, possibly you, has to ask Werner for that fix). Is that accurate? It means we should recommend to Emacs users to use GnuPG 1.x if they want symmetric encryption to be usable (especially caching the passphrase). >> My question now, since we understand the problem well, is if you agree >> with this plan, and if so, do you need patches from me or other >> contributors, or will you address it yourself? There's no urgency >> implied here; I am simply trying to fix this for our users by the next >> Emacs release. DU> Please don't. Don't what? I asked several questions but am clearly waiting for your guidance. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-03 13:59 ` Ted Zlatanov @ 2013-10-03 14:59 ` Stefan Monnier 2013-10-04 21:05 ` Ted Zlatanov 2013-10-04 0:12 ` Daiki Ueno 1 sibling, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2013-10-03 14:59 UTC (permalink / raw) To: emacs-devel > OK, so there's no way to avoid the broken behavior in epg.el and any > fixes on the GnuPG side have to wait until a new release (and someone, > possibly you, has to ask Werner for that fix). Is that accurate? It Can you make a bug report about the problematic behavior (e.g. with your previously posted recipe), and move the discussion there? Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-03 14:59 ` Stefan Monnier @ 2013-10-04 21:05 ` Ted Zlatanov 2013-10-05 16:21 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Ted Zlatanov @ 2013-10-04 21:05 UTC (permalink / raw) To: emacs-devel On Thu, 03 Oct 2013 10:59:13 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: >> OK, so there's no way to avoid the broken behavior in epg.el and any >> fixes on the GnuPG side have to wait until a new release (and someone, >> possibly you, has to ask Werner for that fix). Is that accurate? It SM> Can you make a bug report about the problematic behavior (e.g. with your SM> previously posted recipe), and move the discussion there? I don't think it's worthwhile after this discussion. I'll work around it and see if I can make the workaround generally available. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-04 21:05 ` Ted Zlatanov @ 2013-10-05 16:21 ` Stefan Monnier 2013-10-07 18:15 ` Ted Zlatanov 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2013-10-05 16:21 UTC (permalink / raw) To: emacs-devel > I don't think it's worthwhile after this discussion. I think it is. This whole discussion has been completely muddled because it mixes up details of gpg behaviors with everything else, whereas the only thing that really matters is the behavior of Emacs (which depends on many more things than just gpg) and the problem there is still unclear. > I'll work around it and see if I can make the workaround > generally available. Maybe that's the best we can do, but noone will know until you report this bug with a clear description of the undesirable behavior, so that people can assess really what is the core of the problem and se how we can fix it (since it surely can be fixed in many different ways at different levels). Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-05 16:21 ` Stefan Monnier @ 2013-10-07 18:15 ` Ted Zlatanov 2013-10-07 22:46 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Ted Zlatanov @ 2013-10-07 18:15 UTC (permalink / raw) To: emacs-devel On Sat, 05 Oct 2013 12:21:35 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> I don't think it's worthwhile after this discussion. SM> I think it is. This whole discussion has been completely muddled SM> because it mixes up details of gpg behaviors with everything else, SM> whereas the only thing that really matters is the behavior of Emacs SM> (which depends on many more things than just gpg) and the problem there SM> is still unclear. >> I'll work around it and see if I can make the workaround >> generally available. SM> Maybe that's the best we can do, but noone will know until you report SM> this bug with a clear description of the undesirable behavior, so that SM> people can assess really what is the core of the problem and se how we SM> can fix it (since it surely can be fixed in many different ways at SM> different levels). I reported two bugs about the two different issues (the unavoidable popups and `epa-file-cache-passphrase-for-symmetric-encryption'). I did not elaborate on how unpleasant VCS interactions are because they are just the latter bug over and over. I am not able to develop a workaround as I hoped since my work in the direction of implementing OpenPGP has been rejected. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-07 18:15 ` Ted Zlatanov @ 2013-10-07 22:46 ` Stefan Monnier 0 siblings, 0 replies; 26+ messages in thread From: Stefan Monnier @ 2013-10-07 22:46 UTC (permalink / raw) To: emacs-devel > I reported two bugs about the two different issues (the unavoidable > popups and `epa-file-cache-passphrase-for-symmetric-encryption'). Thank you, Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-03 13:59 ` Ted Zlatanov 2013-10-03 14:59 ` Stefan Monnier @ 2013-10-04 0:12 ` Daiki Ueno 2013-10-04 16:11 ` Ted Zlatanov 1 sibling, 1 reply; 26+ messages in thread From: Daiki Ueno @ 2013-10-04 0:12 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > On Thu, 03 Oct 2013 10:52:46 +0900 Daiki Ueno <ueno@gnu.org> wrote: > > DU> Ted Zlatanov <tzz@lifelogs.com> writes: >>> See my earlier e-mails. But my bigger concern is that for many users, a >>> new GnuPG release is years in the future, so even if you justify this >>> change, it won't help anyone quickly. IMHO epg.el should work around >>> this "feature" now with the --batch --passphrase-fd options that I >>> mentioned, especially if they can work on all GnuPG versions (I haven't >>> tested that). > > DU> Well, that's a design decision not to use --batch here (and probably in > DU> GPGME). If it used --batch, epg.el would need to know a passphrase even > DU> if it is not needed (for example, it is already cached in gpg-agent, > DU> encrypted with empty passphrase, etc.) And also it would inhibit gpg > DU> from doing other user queries until the gpg command terminates. > > OK, so there's no way to avoid the broken behavior in epg.el and any Well, though you say "broken behavior in epg.el", there's clearly a design change in GnuPG side if GnuPG 2.x behaves differently from GnuPG 1.x. You can search on the gpg lists with something like: "gpg agent all secret key", you will find that Werner wanted to move all the secret key operations from gpg to gpg-agent to provide more security. That then ended up with that pinentry needs to be spawned by gpg-agent, not gpg. I think most of your complaint on epg.el are user error and misunderstanding of underlying technical concepts of GnuPG. > fixes on the GnuPG side have to wait until a new release (and someone, > possibly you, has to ask Werner for that fix). Is that accurate? It > means we should recommend to Emacs users to use GnuPG 1.x if they want > symmetric encryption to be usable (especially caching the passphrase). We already recommend that. See (info"(epa) Caching Passphrases"). GnuPG 1.x can coexists with GnuPG 2.x on a single system, and most of distros keep both packages installable without conflict. If you just want to avoid the passphrase prompt, you can simply install both and epg picks the GnuPG 1.x executable first: (defcustom epg-gpg-program (or (executable-find "gpg") (executable-find "gpg2") "gpg") "The `gpg' executable." :group 'epg :type 'string) >>> My question now, since we understand the problem well, is if you agree >>> with this plan, and if so, do you need patches from me or other >>> contributors, or will you address it yourself? There's no urgency >>> implied here; I am simply trying to fix this for our users by the next >>> Emacs release. > > DU> Please don't. > > Don't what? I asked several questions but am clearly waiting for your > guidance. I mean, don't add a workaround using --batch. It's not the right direction: breaks too many things (e.g. smartcard support) and might even add unnecessary passphrase prompts, particularly for non-symmetric key usage. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-04 0:12 ` Daiki Ueno @ 2013-10-04 16:11 ` Ted Zlatanov 0 siblings, 0 replies; 26+ messages in thread From: Ted Zlatanov @ 2013-10-04 16:11 UTC (permalink / raw) To: emacs-devel On Fri, 04 Oct 2013 09:12:34 +0900 Daiki Ueno <ueno@gnu.org> wrote: >> OK, so there's no way to avoid the broken behavior in epg.el and any DU> Well, though you say "broken behavior in epg.el", there's clearly a DU> design change in GnuPG side if GnuPG 2.x behaves differently from GnuPG DU> 1.x. DU> You can search on the gpg lists with something like: "gpg agent all DU> secret key", you will find that Werner wanted to move all the secret key DU> operations from gpg to gpg-agent to provide more security. That then DU> ended up with that pinentry needs to be spawned by gpg-agent, not gpg. DU> I think most of your complaint on epg.el are user error and DU> misunderstanding of underlying technical concepts of GnuPG. I see. I'll find a solution that works for me without epg.el so that there will be no errors and misunderstandings. Thank you for your help. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-29 9:22 bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt Ted Zlatanov 2013-09-29 15:07 ` Thierry Volpiatto 2013-09-29 15:24 ` Daiki Ueno @ 2013-09-30 18:53 ` Stefan Monnier 2013-09-30 19:24 ` Ted Zlatanov 2 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2013-09-30 18:53 UTC (permalink / raw) To: emacs-devel > but with GPG 2.x that seems to be disabled and the pinentry prompt pops > up no matter what. What happens if you redirect stdin from /dev/null? Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-30 18:53 ` Stefan Monnier @ 2013-09-30 19:24 ` Ted Zlatanov 2013-09-30 22:49 ` Stefan Monnier 0 siblings, 1 reply; 26+ messages in thread From: Ted Zlatanov @ 2013-09-30 19:24 UTC (permalink / raw) To: emacs-devel; +Cc: Daiki Ueno On Mon, 30 Sep 2013 14:53:38 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: >> but with GPG 2.x that seems to be disabled and the pinentry prompt pops >> up no matter what. SM> What happens if you redirect stdin from /dev/null? Same outcome. Removing /usr/bin/pinentry is the only way to stop the popup; if I put /usr/bin/pinentry back I get the curses or X popup no matter what: % echo x > /tmp/t % mv /usr/bin/pinentry /usr/bin/pinentry.bak % gpg --passphrase-fd=0 --decrypt authinfo.gpg < /tmp/t gpg: CAST5 encrypted data gpg-agent[28972]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[28972]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: encrypted with 1 passphrase gpg: decryption failed: No secret key % mv /usr/bin/pinentry.bak /usr/bin/pinentry % gpg --passphrase-fd=0 --decrypt authinfo.gpg < /tmp/t (pinentry query UGH) Oh, I finally found a workaround! No idea if it would work in the GnuPG 2.1 release Ueno-san mentioned because I can't find a 2.1, but this worked for me with 2.0.20: gpg --passphrase-fd=0 --batch --decrypt authinfo.gpg < /tmp/t This mode is not used in epg.el right now, so the popup keeps happening. I can try to patch this myself but it seems, with the potential GnuPG 2.1 and the other pinentry developments mentioned by Ueno-san, that I should leave this to him because I don't know the full story. The obvious fix here could break something else with the next release. Should I open a bug, then, with the suggested workaround? Or wait? The multiple popups are really annoying. Thanks! Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-30 19:24 ` Ted Zlatanov @ 2013-09-30 22:49 ` Stefan Monnier 2013-09-30 23:34 ` Ted Zlatanov 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2013-09-30 22:49 UTC (permalink / raw) To: emacs-devel > Should I open a bug, then, with the suggested workaround? Or wait? The > multiple popups are really annoying. I must say I don't really understand what is the problem you're describing (I mean: in what way does it affect Emacs), so I'll let you judge. AFAIK it's perfectly OK to popup a password prompt when needed and I don't know under what circumstance this would be a problem. Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-30 22:49 ` Stefan Monnier @ 2013-09-30 23:34 ` Ted Zlatanov 2013-10-01 0:40 ` Stefan Monnier 2013-10-01 2:23 ` Stephen J. Turnbull 0 siblings, 2 replies; 26+ messages in thread From: Ted Zlatanov @ 2013-09-30 23:34 UTC (permalink / raw) To: emacs-devel On Mon, 30 Sep 2013 18:49:11 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Should I open a bug, then, with the suggested workaround? Or wait? The >> multiple popups are really annoying. SM> I must say I don't really understand what is the problem you're SM> describing (I mean: in what way does it affect Emacs), so I'll let SM> you judge. SM> AFAIK it's perfectly OK to popup a password prompt when needed and SM> I don't know under what circumstance this would be a problem. Using symmetric (passphrase) encryption: open authinfo.gpg in a buffer -> prompt edit save -> prompt VCS commit -> 2 or 3 prompts 4-5 prompts, I lost counts. This is the default behavior with GnuPG 2.0.20 and can't be turned off in a config file. To fix it, epg.el must be changed to use `--passphrase-fd=0 --batch' as I found today. The old behavior was, when GPG_AGENT_INFO was disabled, to ask for the password in an Emacs prompt. That fix doesn't work now. Daiki Ueno, however, told me the behavior was different in 2.1 with --pinentry-mode=loopback but I can't find such a release even though I found the commit. So I have no idea what the right fix is, at this point. I hope that summary helps. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-30 23:34 ` Ted Zlatanov @ 2013-10-01 0:40 ` Stefan Monnier 2013-10-01 1:13 ` Ted Zlatanov 2013-10-01 2:23 ` Stephen J. Turnbull 1 sibling, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2013-10-01 0:40 UTC (permalink / raw) To: emacs-devel SM> AFAIK it's perfectly OK to popup a password prompt when needed and SM> I don't know under what circumstance this would be a problem. > Using symmetric (passphrase) encryption: > open authinfo.gpg in a buffer -> prompt > edit > save -> prompt > VCS commit -> 2 or 3 prompts I don't see how that relates to your previous question, which was about preventing the prompt from appearing at all, rather than about making sure that previous passwords are recorded and reused in subsequent uses. Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-10-01 0:40 ` Stefan Monnier @ 2013-10-01 1:13 ` Ted Zlatanov 0 siblings, 0 replies; 26+ messages in thread From: Ted Zlatanov @ 2013-10-01 1:13 UTC (permalink / raw) To: emacs-devel On Mon, 30 Sep 2013 20:40:08 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: SM> AFAIK it's perfectly OK to popup a password prompt when needed and SM> I don't know under what circumstance this would be a problem. >> Using symmetric (passphrase) encryption: >> open authinfo.gpg in a buffer -> prompt >> edit >> save -> prompt >> VCS commit -> 2 or 3 prompts SM> I don't see how that relates to your previous question, which was about SM> preventing the prompt from appearing at all, rather than about making SM> sure that previous passwords are recorded and reused in subsequent uses. I see. Sorry for confusing you. Here's what I wrote originally: TZ> It used to be possible to do TZ> GPG_AGENT_INFO=none gpg --decrypt foo.gpg TZ> GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg TZ> etc. TZ> but with GPG 2.x that seems to be disabled and the pinentry prompt pops TZ> up no matter what .... TZ> The effect to Emacs users is that the pinentry passphrase dialog comes TZ> up over and over, at least in X. It makes working with .gpg files (in TZ> VCS in particular) practically unusable and I haven't found a way to TZ> disable the pinentry prompt. So very specifically, the external pinentry prompt is preventing the `epa-file-cache-passphrase-for-symmetric-encryption' defcustom from operating properly. Ideally I don't want the initial graphical popup either--it's very annoying--but I can live with one popup. Ted ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt 2013-09-30 23:34 ` Ted Zlatanov 2013-10-01 0:40 ` Stefan Monnier @ 2013-10-01 2:23 ` Stephen J. Turnbull 1 sibling, 0 replies; 26+ messages in thread From: Stephen J. Turnbull @ 2013-10-01 2:23 UTC (permalink / raw) To: emacs-devel Ted Zlatanov writes: > be changed to use `--passphrase-fd=0 --batch' as I found today. > --pinentry-mode=loopback I bet the implementation of the latter is the former. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2013-10-07 22:46 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-09-29 9:22 bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt Ted Zlatanov 2013-09-29 15:07 ` Thierry Volpiatto 2013-09-29 17:48 ` Ted Zlatanov 2013-09-29 15:24 ` Daiki Ueno 2013-09-29 17:57 ` Ted Zlatanov 2013-10-02 7:23 ` Daiki Ueno 2013-10-02 10:34 ` Ted Zlatanov 2013-10-02 12:48 ` Daiki Ueno 2013-10-02 13:27 ` Andrey Kotlarski 2013-10-02 13:38 ` Ted Zlatanov 2013-10-03 1:52 ` Daiki Ueno 2013-10-03 13:59 ` Ted Zlatanov 2013-10-03 14:59 ` Stefan Monnier 2013-10-04 21:05 ` Ted Zlatanov 2013-10-05 16:21 ` Stefan Monnier 2013-10-07 18:15 ` Ted Zlatanov 2013-10-07 22:46 ` Stefan Monnier 2013-10-04 0:12 ` Daiki Ueno 2013-10-04 16:11 ` Ted Zlatanov 2013-09-30 18:53 ` Stefan Monnier 2013-09-30 19:24 ` Ted Zlatanov 2013-09-30 22:49 ` Stefan Monnier 2013-09-30 23:34 ` Ted Zlatanov 2013-10-01 0:40 ` Stefan Monnier 2013-10-01 1:13 ` Ted Zlatanov 2013-10-01 2:23 ` Stephen J. Turnbull
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.