I think the problem is that your key export fails, because you pointed
--homedir at the (presumably) empty directory "%tmp%\_tempKeyring".

The export did not use any filter and tried to export a key as can be seen in
Msg8313 "error receiving key from agent"
The import itself also stated no errors as it can be seen in T2355 (dranft on May 12 2016, 03:00 PM / Roundup), but this
imported secret key cannot be used (or exported) anymore.
Also important: This is no longer reproducible in 2.1.14 (which might be enough
to set the bug to fixed)

I don't believe this demonstrates a bug.

I think the problem is that your key export fails, because you pointed --homedir at the (presumably)
empty directory "%tmp%\_tempKeyring". This leads to the not very helpful error message about the
eof. If the export were successful, gpg would have written the key to stdout.

For reference, here is what I tried. First GNUPGHOME points to a home with the key I want to export:

    $ echo $GNUPGHOME
    /tmp/tmp.T7I4M9RIc3
    $ g10/gpg --list-keys alpha
    gpg: please do a --check-trustdb
    pub   dsa1024 1999-03-08 [SCA]
          A0FF4590BB6122EDEF6E3C542D727CC768697734
    uid           [ unknown] Alfa Test (demo key) <alfa@example.net>
    uid           [ unknown] Alpha Test (demo key) <alpha@example.net>
    uid           [ unknown] Alice (demo key)
    sub   elg1024 1999-03-08 [E]

You need some kind of pinentry program, because you may be asked for the current passphrase or an
export passphrase:

    $ cat $GNUPGHOME/gpg-agent.conf
    pinentry-program /usr/bin/pinentry-x11

Now export the key:

    $ g10/gpg --export-secret-keys alpha >/tmp/alpha.gpg

Now I create an empty home, and import the key in batch mode:

    $ export GNUPGHOME=$(mktemp -d)
    $ g10/gpg --batch --import /tmp/alpha.gpg
    gpg: keybox '/tmp/tmp.bL2caQmZri/pubring.kbx' created
    gpg: /tmp/tmp.bL2caQmZri/trustdb.gpg: trustdb created
    gpg: key 2D727CC768697734: public key "Alfa Test (demo key) <alfa@example.net>" imported
    gpg: key 2D727CC768697734: secret key imported
    gpg: Total number processed: 3
    gpg:               imported: 1
    gpg:       secret keys read: 3
    gpg:   secret keys imported: 2

Could you please check if that works for you?

Hi, thanks for testing master.

I can semi reproduce this. For me it works the first time but a second call to
getpin fails.

$ ./pinentry-gtk-2
OK Pleased to meet you
getpin
D hello
OK
getpin

• (pinentry-gtk-2:29090): CRITICAL **: could not grab keyboard

ERR 83886179 Operation cancelled <Pinentry>

And indeed this goes away with f4b5049c68a79d5e4faba06447db5440936cefeb~1

Looking at the code I don't see a reason for this. Maybe the dialog?
The code without the dialog 71b51e02cf20174ba7144765e985f7e889eaa429 also allows
me to repeatedly call getpin.

Werner: Any idea? I'm a bit clueless which change in the patch could have caused
that.

Please report this to Debian. This is not a part of upstream Pinentry.

PS: forget the --homedir thing, it is even reprodicable in the default folder in
%appdata%.

Sorry, forgot my import cmdline:

C:\Program Files (x86)\GNU\GnuPG\2.1.12\bin>gpg --batch --homedir
%tmp%\_tempKeyring --import "P:\2EEC2B65A2B4B3EF.sec.asc"
gpg: Die "Keybox" `C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/pubring.kbx'
wurde erstellt
gpg: C:/Users/ranftd/AppData/Local/Temp/_tempKeyring/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel A2B4B3EF: Öffentlicher Schlüssel "Daniel Ranft (Giegerich &
Partner GmbH)" importiert
gpg: Schlüssel A2B4B3EF: "Daniel Ranft (Giegerich & Partner GmbH)" nicht geändert
gpg: Schlüssel A2B4B3EF: geheimer Schlüssel importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 4
gpg: importiert: 1
gpg: unverändert: 1
gpg: gelesene geheime Schlüssel: 3
gpg: unveränderte geh. Schl.: 2
gpg: keine ultimativ vertrauenswürdigen Schlüssel gefunden

I've now pushed a patch to the GTK variant based on werner's original work with
the message box and the string button labels.

I was unable to get the tab order working correctly so that the visibility
button comes last in GTK. I've tried it with gtk_container_set_focus_chain but
it did not work as expected. When set on the wvbox it disabled tab changes
altogether. When set on the cbbox or bbbox it somewhat worked (e.g. when I
removed a widget from my list it was no longer tabbable) but it would not add
the repeat edit and the visibility toggle button although both were part of my list.
Probably a problem because of the sublayouts?

I noted this in the code so if someone wants to change that you are welcome :-)

Am Donnerstag, 14. April 2016 16:24:59 schrieb Andre Heinecke via BTS:

But from the discussion here and back then I took that draft to be no
longer up to date and that the MessageBox Question approach with small icon
buttons is not wanted.

I know your first draft.

But from the discussion here and back then I took that draft to be no longer up
to date and that the MessageBox Question approach with small icon buttons is not
wanted.

I also don't know where we agreed that an Eye icon is a bad idea for this action.
This icon in similar to the one of the Windows Login screen and the same one
used in KDE. So it is recognizable for this action.

If you strongly favor the Message box variant I can change it to that.

No string changes in gpg-agent please.

I though we agreed that a watching eye is not a good icon for various reasons?

For the GTK version I already proposed a different layout:
it is still available at https://wiki.gnupg.org/ScratchWK . That fallback
solution tales away to much real estate

Better screenshot of the fallback showing a real call by gpg-agent instead of a
"getpin"

Neal: I've commited this with: 71b51e02cf20174ba7144765e985f7e889eaa429

The Make passphrase visible is in the tab order after the line edit. I don't
know how to best change this in GTK and the "Save passphrace using libsecret"
button would have the same problem.

I don't think it's a real problem though as you would have to tab + space to
make the password visible. Tab + Enter would just accept the dialog.

If you think this ok you can set this issue to resolved. You can also change the
setting you mentioned in T2139 (neal on Dec 07 2015, 10:09 AM / Roundup) . I don't know how. :-)

We might want to change the strings in gpg-agent though. I would prefer: "Show
passphrase" instead of "Make passphrase visible".

Fallback variant. (Qt5 Version with XDG_CURRENT_DESKTOP=GNOME)

The checkbox comes after the cancel button in the Tab order and will not
activate when pressing enter.

This is how I'll add it to the GTK variant now.

I've implemented this for Qt now.

The Qt5 variant with breeze icon theme looks like the attached screenshot. This
is how it will look on Windows and for KDE plasma 5 users.

If the Qt version is too old (The API for the line edit action was added in
Qt5.2) or there is no icon for the visibility actions it falls back to a textual
checkbox.
This also avoids licensing problems with the icons as the icons are loaded
through QIcon::fromTheme.

No, FLTK is not lightweight. It actually adds the requirement for a C++
compiler to GnuPG. And pinentry-w32 shall of course not die!

Werner what is your opinion on this?

pinentry-w32 is broken. It does not handle variable string sizes and there is no
easy way to fix that. Afaik it was never intended as the "default" windows
pinentry but only as a crutch for windows ce experiments.

Would fltk be lightweight enough for your to replace pinentry-w32 in your
installer? In that case I think we should take a serious look at this patch as a
minimal pinentry version for windows.

(And delete pinentry-w32 instead)

I think this can be resolved. Yes older versions did not allow pasting but
recent versions do allow this. So we've fixed the bug in recent versions ->
resolved. No?

The reporter says he is using ubuntu 14 (i assume 14.4) where the default
pinentry is pinentry-gtk2 0.8.3

What is the output of

  gpgconf --list-dirs

?

Yes you are using pinentry, and we need to know what kind of pinentry (there are
several flavors) and which version you are using in order to help you.

Please do 'pinentry --version' and report the output.

To see whether this pinentry is the one you are using, or to play around with it
and the variants, you can do:

echo -e "SETDESC Does this look like your pinentry window?\nGETPIN" | pinentry

You can try replacing pinentry with pinentry-qt for example.

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.

I think this is reasonable. If you want to implement it, I'll review the
patches. Thanks.

I wonder if we could / should use this as a replacement for Pinentry-w32?

Pinentry-w32 should die and FLTK could be lightweight enough that werner would
include it in gnupg-w32?

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.

I tend to agree with Werner: adding another pinentry program increases our
maintenance burden, but the new pinentry doesn't add any convincing features,
AFAIK. If there are some significant benefits, please add them. Otherwise, I
think I'll change this issue to wont-fix. Sorry. Nevertheless, thank you for
your contribution! I hope you'll find another way to contribute.

Does this mean that pinentry-emacs will only work when an emacs instance calls
gpg? Does pinentry-emacs need to support the case that a program other than
emacs calls gpg?

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

@ueno: This is reasonable. Thanks for the explanation. Do you happen to know
approximately what version started to enable these protections?

Given that FLTK is a C++ library and we already have a Qt frontend, I am not
sure whether adding this is a good idea. The problem is the usual ABI break due
to compiler or library changes. We already had our problems in the past with
the two Qt versions we supported. Adding FLTK would introduce those problems again.

Why are Qt or GTK+ not sufficient for small boxes?

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

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.

"There are not many comments."
The code should comment itself, and /* some comment for block */ really need
only for description the strongly non-obvious actions - like complex math,
optimization (with answer why optimize here) or factorization algorithm O(1) :-).

Dear Neal, I thank you for answer.

This issue's the main goal is getting an answer to a question - Do you plan
support FLTK. I suppose that it may be closed with comment "not need this
toolkit" - so I do not format according to the GNU coding standards - There are
many contentious issues about the format code - 80 chars per line is more then
enough for assembler, but for C++ with templates - not sure.
Your code is your rules, so If you plan to accept FLTK support - I fix all notes.

"Using email"
email "madrat@users.noreply.github.com" is also my email, which I use in
github.com and because I use local git, it will be inserted automatically.

"the rest of the code has a fair number of violations"
For my studies and knowledge - can you post sample of violation?

I reported this to the libsecret maintainers, but it turns out that it was our
bug. Stef kindly replied a patch, which I've now applied (2f5bfa0). Looking
again at dkg's original message, he doesn't suggest that the problem is with
libsecret, but in fact correctly identified pinentry at the culprit.

see attached, this is a part of gpg, enter password, I need to be able
to paste into that field. Nobody seems to know how to fix this!

I'm not using pinetry, it is part of the pgp software. just trying to
get to the bottom of this. I am a user, not a programmer. Pinetry just
makes the popup that's asking for the password. I attached a screenshot
of it.

This is Linux From Scratch, pinentry 0.9.7, pinentry -> pinentry-gtk-2, with
fallback to ncurses. No other pinentry program works.

This is KDE environment, Qt pinentry crashes. I can confirm that there's a
keyring password in the Login keyring, which is the only keyring I use.

Nonetheless, the password won't be asked again while the gpg-agent is running,
the password was entered at least once, and the "Remember password (or
whatever)" box was checked.

As soon as gpg-agent is terminated or a session restarted (which also terminates
gpg-agent), next time I try to use the pgp key, I get asked for its passphrase.

What distribution are you using? What pinentry program? Can you take a look
using seahorse to make sure that your password is saved. Once it is saved, it
shouldn't be removed.

Note: recent versions of pinentry-gtk-2 are using native widgets. If you are
using that program and not the latest version of pinentry, then please try that
first.

There is no version 2.0.22 of pinentry (the most recent version is 0.9.7). Can
you please figure out what version of pinentry you are using and which pinentry
program (there are five: pinentry-gnome3, pinentry-gtk-2, pinentry-qt,
pinentry-curses and pinentry-tty). Thanks!

I think I wasn't clear. I have two monitors, but only one X DISPLAY. This is
about the screen, not the X display, where the pinentry is shown.

You may use gpg-agent's --keep-display to force the pinentry to show up on the
display you started the agent. The agent needs to be started explicit, though.

A library should never ever send any diagnostics to stdout. That does not only
break pinentry but also all other tools which output to stdout. I suggest to
report that to libsecret.

Hm, this is indeed fixed for pinentry-gtk2 and pinentry-gnome3, but pinentry-qt
is still broken:

0 $ DISPLAY=:3 pinentry-qt
QXcbConnection: Could not connect to display :3
Aborted
134 $

Yes, pasting into pinentry-gtk-2 with the middle mouse button does work.

I noticed that pinentry-gnome3 uses GcrSystemPrompt, which is documented as
being a system modal prompt. I'm not very familiar with libgcr, but maybe
pinentry-gnome3 could use GcrPromptDialog if no-grab is set.

The gnome3 problem is due to libgcr, which disables and manages the dialog.

I'll take a look at the gtk2 issue soon. Does pasting with the middle mouse
button work?

Actually there is something more.

While using pinentry-gtk-2 in a terminal does work, it still fails in
Thunderbird/Enigmail (passphrase not recognized).

And pinentry-gnome3, that works in the terminal too, doesn’t work in
Thunderbird/Enigmail as stated before (it fails just like if set to pinentry-tty
or pinentry-curses).

So, found it why trying what you asked me for.

It has to do with Input Method. GTK3 is working because it’s the only toolkit
that properly recognize all the dead keys on my setup (some of the characters I
use are only available through dead keys). QT4 was working because of this line
in my .xprofile:

export QT4_IM_MODULE=xim

Replacing QT4 with GTK makes pinentry-gtk-2 work too. However, this seems not
supported by QT5 (the correct var is QT_IM_MODULE), because xim seems to be
obsolete so they don’t support it. But some of my dead keys are not working, so
this is most likely a bug on QT/KDE side…

And since I run a QT5 terminal, -curses and -tty don’t work.

So, I think this can be closed, and that it’s time to open/search a bug
regarding this on QT/KDE side.

if there is a behavioral change regarding the encoding a difference between qt4
and qt5 this would be a bug. Both convert the input to UTF-8, I think GTK does
too. I've just tested it and it worked.

So they should be the same. Can you provide an example test case by starting
pinentry from the command line and using "getpin"?

There is no encoding at all for passphrase - GnUPG uses whatever the user types.
Thus if the passphrase was originally entered on a Latin-1 TTY and later a GUI
with UTF-8 input is used, you run into problems.

We can't cange that because that breaks existing passphrases. For new
installations it should not be a problem becuase modern systems are all UTF-8
(modulo Windows)

I wonder if it is an encoding problem.