Page MenuHome GnuPG
Feed Advanced Search

Jun 22 2017

ueno added a comment to T3217: pinentry-curses and emacs don't play well together.

It's not possible, unless you convince the Emacs developers to add special support for it. See http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00798.html.

Jun 22 2017, 3:35 PM · pinentry, Bug Report

Feb 26 2016

ueno added a comment to T2263: use FD passing instead of /tmp/emacs$UID/pinentry.

I have done some experiment with it, and it works (though I had
to add ASSUAN_*_FDPASSING flags to a couple of places in gnupg).
However, I think I still need some more opinions to make it a
reviewable state.

First, to make all the things work, gpg would need a new
option (or an envvar?) to tell the FD number. Naively, it could
be named as --emacs-fd, which only works if INSIDE_EMACS is set.
However, it might be too specific, and sounds over-engineering to
me.

Instead, we could add a more generic option, say, --pinentry-fd.
With that option, any pinentry could talk to the caller through
the FD with the Assuan protocol. For security, the effect of the
option shall be restricted only when --pinentry-mode=loopback is
set and working.

In that case, it's tempting to make gpg-agent directly talk to
the FD, instead of spawning pinentry. However, it cannot take
advantage of pinentry's libsecret support and the diversion to
other pinentries (GTK+, ...). Also, it might be a similar
concept of --pinentry-program, which I proposed and was rejected.

What do you think?

Actually, I'm not sure about the current recommendation on the
custom passphrase input options. Given the recent bug fixes,
could --pinentry-mode=loopback be publicly promoted? If so,
I'm happy to withdraw this (and perhaps INSIDE_EMACS stuff) and
add a hack to use --pinentry-mode=loopback.

Feb 26 2016, 10:09 AM · pinentry, Feature Request

Feb 24 2016

ueno added a comment to T2263: use FD passing instead of /tmp/emacs$UID/pinentry.

Does this mean that pinentry-emacs will only work when an emacs instance calls

gpg?

Yes, it is the intention of this proposal.

Does pinentry-emacs need to support the case that a program other than

emacs calls gpg?

I don't think it is worth being supported. It would be rather confusing if a
GUI program internally using gpg asked passphrases from Emacs window.

Feb 24 2016, 3:09 AM · pinentry, Feature Request

Feb 23 2016

ueno set Version to 0.9.7 on T2263: use FD passing instead of /tmp/emacs$UID/pinentry.
Feb 23 2016, 8:29 AM · pinentry, Feature Request
ueno added projects to T2263: use FD passing instead of /tmp/emacs$UID/pinentry: Feature Request, pinentry.
Feb 23 2016, 8:29 AM · pinentry, Feature Request
ueno added a comment to T2034: pinentry emacs features need documentation.

It has been there since the 21.1 release. The relevant commits are:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b021ef186f6062705a29ae8e3840ad32db451811
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=719349f6d0e464d4f71963b87f6bfa08ac630aa7

Feb 23 2016, 8:14 AM · Bug Report, pinentry

Feb 22 2016

ueno reopened T2034: pinentry emacs features need documentation as "Open".
Feb 22 2016, 3:18 AM · Bug Report, pinentry
ueno added a comment to T2034: pinentry emacs features need documentation.

D315: 782_0001-doc-Make-Emacs-frontend-description-more-accurate.patch

Feb 22 2016, 3:18 AM · Bug Report, pinentry
ueno added a comment to T2034: pinentry emacs features need documentation.

Thanks for writing this up, Neal. However, I found the claim a bit
inaccurate by now. I am attaching a proposed fix for this.

Emacs keeps all key presses buffered.
(You can see the recent key presses by typing @code{C-h l}
(@code{view-lossage}) in emacs.)

This is not the case with the common `read-passwd' function, which
clears the log on every key press. See:
http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/subr.el#n2126

Because of this concern, Emacs doesn't
enable this by default (the user has to run @code{(pinentry-start)},
e.g., from his or her @code{.emacs} file, explicitly).

This is no longer true. Emacs checks the allow-emacs-pinentry option
of gpg-agent, and start it if desired.

Further, Emacs is a huge program,
which doesn't provide any process isolation to speak of. As such,
having it handle the passphrase adds a huge chunk of code to the
user's trusted computing base.

Yes. However, all official packages on elpa.gnu.org are digitally
signed and supposed to work courteously. Users can still use unsigned
or 3rd party packages, but I think it is similar to the situation
where distribution packages are used.

In conclusion, I would say the Emacs pinentry provides the same level
of security as the current pinentry-gtk2 (as long as the
implementation is sane). My only concern was that Emacs `read-passwd'
is implemented in Elisp and thus cannot use secure memory. However,
it is also true for pinentry-gtk2, which uses the default GtkEntry
now.

Feb 22 2016, 3:18 AM · Bug Report, pinentry

Aug 18 2015

ueno added a comment to T1985: Option --try-all-secrets doesn't work.

D304: 668_0001-Make-try-all-secrets-work-for-hidden-recipients.patch

Aug 18 2015, 10:17 AM · gnupg (gpg21), Bug Report, gnupg
ueno added a comment to T1985: Option --try-all-secrets doesn't work.

I have also encountered this while testing the --throw-keyids option with 2.1.6.
It seemed to me that the fix is not that hard, so I'm attaching a patch.

Aug 18 2015, 10:17 AM · gnupg (gpg21), Bug Report, gnupg

May 19 2015

ueno added a comment to T1976: loopback pinentry mode asks passphrase twice on symmetric encryption.

Regarding custom pinentry program, doesn't that mean to require a user to edit
gpg-agent.conf to enable/disable the custom pinentry program?

Yes, pinentry-emacs could implement the fallback mechanism to pinentry-gtk (i.e.
by checking if Emacs is running), but I think it is too much.

Perhaps gpg could have a --pinentry-program option too and pass the value to
gpg-agent?

May 19 2015, 10:34 AM · Bug Report, gnupg

May 13 2015

ueno added a project to T1976: loopback pinentry mode asks passphrase twice on symmetric encryption: gnupg.
May 13 2015, 1:02 AM · Bug Report, gnupg
ueno added a project to T1976: loopback pinentry mode asks passphrase twice on symmetric encryption: Feature Request.
May 13 2015, 1:00 AM · Bug Report, gnupg
ueno set Version to 2.1 on T1976: loopback pinentry mode asks passphrase twice on symmetric encryption.
May 13 2015, 1:00 AM · Bug Report, gnupg
ueno set External Link to http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20550#17 on T1976: loopback pinentry mode asks passphrase twice on symmetric encryption.
May 13 2015, 1:00 AM · Bug Report, gnupg

Dec 27 2010

ueno set Version to svn on T1309: typo in gpgme_op_{keylist,trustlist}_end doc.
Dec 27 2010, 3:21 AM · gpgme, Bug Report
ueno added a comment to T1309: typo in gpgme_op_{keylist,trustlist}_end doc.

D146: 322_gpgme-list-end-doc.patch

Dec 27 2010, 3:21 AM · gpgme, Bug Report
ueno added projects to T1309: typo in gpgme_op_{keylist,trustlist}_end doc: Bug Report, gpgme.
Dec 27 2010, 3:21 AM · gpgme, Bug Report

Nov 10 2010

ueno added a comment to T1295: link dirmngr_ldap with -llber.

D144: 317_gnupg-2.1-liblber.patch

Nov 10 2010, 3:29 AM · dirmngr, Bug Report
ueno added projects to T1295: link dirmngr_ldap with -llber: gnupg, Bug Report.
Nov 10 2010, 3:29 AM · dirmngr, Bug Report
ueno added projects to T1294: typo in libgcrypt/tests/Makefile.am (GPG_ERROR_LIBS): libgcrypt, Bug Report.
Nov 10 2010, 2:37 AM · Bug Report, libgcrypt
ueno added a comment to T1294: typo in libgcrypt/tests/Makefile.am (GPG_ERROR_LIBS).

D143: 316_libgcrypt-tests-ldadd.patch

Nov 10 2010, 2:37 AM · Bug Report, libgcrypt

Jul 1 2009

ueno added projects to T1079: S-expression doc fix: libgcrypt, Bug Report.
Jul 1 2009, 11:08 AM · Bug Report, libgcrypt
ueno added a comment to T1079: S-expression doc fix.

D98: 233_doc-sexp.diff

Jul 1 2009, 11:08 AM · Bug Report, libgcrypt
ueno added a comment to T1078: Minor typo in translations of "Really move the primary key? (y/N) ".

The translation in zh_TW.po looks good, but the one in zh_CN.po doesn't. It
contains the kanji sequence "删除" (U+5220, U+9664) which is very close to "削
除" (U+524a, U+9664, "remove" in Japanese) in shape.

Jul 1 2009, 5:44 AM · Bug Report, gnupg

Jun 26 2009

ueno added projects to T1078: Minor typo in translations of "Really move the primary key? (y/N) ": gnupg, Bug Report.
Jun 26 2009, 9:40 AM · Bug Report, gnupg
ueno added a comment to T1078: Minor typo in translations of "Really move the primary key? (y/N) ".

D97: 232_po-typo.diff

Jun 26 2009, 9:40 AM · Bug Report, gnupg