--debug-pinentry is an option for the gpg-agent. Thus put the line

debug-pinentry

into gpg-agent.conf and make sure that there is also a log-file option.

I compiled pinentry version 0.9.5 and tried to regenerate my keys. The good news
is that the curses window appeared and I could enter my passphrase. The bad news
is that after I entered the passphrase(with the repetition), the program
freezed, not returning any prompt and not giving any sign of life(I checked with
top to be sure and nothing).

Also, when I tried to use the --debug-pinentry, gpg didn't recognize it as a
valid argument. I use gpg 2.1.6.

D295: 667_0002-enforce-std-gnu-11-to-avoid-breakage-with-gcc5.patch

the attached patch is a minimal patch to make older versions of pinentry-qt4
build cleanly with newer gcc.

Please update to pinentry 0.95 and try again. You may also use the gpg-agent
option --debug-pinentry which shows the communication between gpg-agent and
pinentry.

pinentry-curses 0.9.1

Which pinentry version are you using?

This will be fixed in the upcoming pinentry release as pinentry-qt no longer
uses std::string

gpg-agent requires that you add
--enable-emacs-pinentry.
to gpgagent.con. This is similar to
--no-allow-external-cache
but even not enabled by default.

Thanks for testing this!

@neal. Just pulled master and gave it a try. Role is correct, events are correct,
and Orca's working as expected with that widget. Thanks much!!

This was done with 26ab44b.

I'm now using pinentry-qt5 as my main pinentry but I doubt that there will be
any problems. After dropping the "Secure widgets" There were no code changes
necessary to support Qt5.

Duplicate of T2057

Duplicate of T2058

Duplicate of T2059

The documentation part of this bug should now be resolved. There are three
other issues. I've opened separate issues in the tracker for them.

I've added some documentation. Let me know if it needs further improvement.
Thanks.

I replaced our custom entry widget with the standard Gtk+ widget. This makes
the changes to the secure entry redundant. I did apply the tooltip changes
(c9c3576) and the gtk_widget_get_window changed (70a106) from your patch. Thanks.

I replaced our custom entry widget with the standard Gtk+ widget. This should
fix this problem. Please test and let me know either way. Thanks!

I replaced our custom entry widget with the standard Gtk+ widget. This should
fix this problem. Please test and let me know either way. Thanks!

Hi, I've just replaced the use of our custom entry widget with the standard Gtk+
entry widget. This should fix the problem. Please report back whether this is
the case. Thanks.

Thanks for the feedback. Closing.

0003-build-sync-qt4-pkg-config-behavior-with-other-pkg-co.patch - on top

optional

sync qt4 pkg-config behaviour

D317: 660_0003-build-sync-qt4-pkg-config-behavior-with-other-pkg-co.patch

0002-build-use-pkg.m4-for-pkg-config-usage.patch - on top

remove the manual pkg-config usage, as build already use pkg.m4 macros there is
no reason to use manual pkg-config

D318: 659_0002-build-use-pkg.m4-for-pkg-config-usage.patch

The security issue with emacs pinentry is that emacs is handling the passphrase
and it isn't very careful with it. For instance, try typing C-h l
(view-lossage) in emacs. This will show you your recent keystrokes. Emacs is
also a huge program (operating system?), which doesn't provide any isolation to
speak of. So, having it handle the passphrase adds a huge chunk of code to the
user's trusted computing base. Because of this concern, emacs doesn't enable
this by default (the user has to add pinentry-start to his or her .emacs files).

Emacs support in pinentry of course adds some complexity to pinentry and a
minuscule amount of additional complexity to gpg agent (it needs to pass through
a few more environment variables).

You propose an attack in which an attacker has access to the gpg-agent socket
and some other socket. pinentry is wired to use /tmp/emacs<UID>/pinentry. So I
guess this is the other socket that you mean. Note: before using it, pinentry
makes sure that the socket is owned by UID.

As far as I can see there are two weaknesses. First, the attacker can try to
brute force the password. This is a minor problem, I think, but worth
addressing given the recent efforts to prevent this type of attack. Based on
how unlikely and difficult this attack is, I think the best thing to do is for
gpg-agent to rate limit pinentry. Second, the attacker could exploit a weakness
in the gpg-agent/pinentry API. My sense here is that there are probably easier
attack vectors. As Werner likes to say: there are many local exploits. Once
the attacker has your UID, he or she can just ptrace your gpg-agent or copy your
private key (assuming it is saved on disk).

I propose the following:

• Add a command line option to pinentry that disables emacs support
• Change gpg-agent to support passing command line options to pinentry
• Rate limit password attempts by pinentry.
• Document pinentry-emacs and related functionality in the pinentry manual.

Is this reasonable?

If pinentry-emacs doesn't need to be distributed, why do we even have it as a
separate target (emacs/pinentry-emacs) that is enabled by default?

my concern about abuse of INSIDE_EMACS is as i said "vague" -- sorry, i hope
it's not FUD! here's a rough sketch:

pinentry is a sensitive program. its job is to protect sensitive data (secret
key material, passphrases) from unintended use. each hook that we put into
pinentry to allow an attacker to probe its contents, or to execute commands, or
to control the UI/UX of what is presented to the user, is another hook that can
be used to violate the protection we want gpg-agent to afford its users.

Consider an attacker who has access only to the gpg-agent socket, and to one
other socket on the system. If they can convince gpg-agent to talk to them on
that one other socket by setting INSIDE_EMACS during a communication to
gpg-agent, this seems like a risk. furthermore, it's an unnecessary risk for
users who have no intention of interacting with gpg-agent through emacs in this
way. (e.g. users of emacs under X11 sessions may prefer to use a graphical
agent, or users of emacs from a terminal may prefer pinentry-curses). it's not
clear if there's a way to tell gpg-agent at runtime to avoid this additional
communications vector either.

pinentry-emacs does not need to be distributed. You just need to distribute the
usual pinentry programs with emacs support. Similar to the fallback-curses
mode, if these programs see that INSIDE_EMACS is set AND they can talk to an
emacs instance with the pinentry module loaded, then they speak the emacs
protocol. Otherwise, they do their usual thing.

I'll update the documentation in the near future.

What abuse of INSIDE_EMACS are you referring to?

Thanks

Looks like the actual issue was that gpg-agent wasn't running.

Works fine now. Thanks for your help.

gpg agent already handles caching passwords in memory; Gnome keyring is just
used to cache the passwords on stable storage. Thus, I think the current
behavior is correct. If you disagree, please reopen and describe the behavior
that you expect.

Note: to have gpg agent cache passwords for a long time, set default-cache-ttl
and max-cache-ttl in your gpg-agent.conf to large values. To make sure the
cache is cleared when you log out, use 'gpgconf --reload gpg-agent' (or use send
SIGHUP to the right gpg-agent).

chdiza: In the future, please open one issue per bug report. FWIW, I've also
fixed this new bug.

Given that this bug has existed since forever on Max OS X, I don't think this
issue is important enough to immediately do a release. However, there should be
a new release within the month.

Also, the OSX community would much appreciate it if you guys would cut a release
containing this fix as soon as possible. We aren't any less likely to misenter our own
passwords than anyone else :)

Neal: It works!

However you should be aware that I had to manually --disable-pinentry-emacs, or else
I got this:

-----8<-----------------------------
Making all in emacs
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/Cellar/gnoopeegee/1.8.0/include -
I/usr/local/Cellar/gnoopeegee/1.8.0/include -I../pinentry -Wall -g -O2 -Wall -
Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security
-W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -
Wno-pointer-sign -Wpointer-arith -MT pinentry-emacs.o -MD -MP -MF .deps/pinentry-
emacs.Tpo -c -o pinentry-emacs.o pinentry-emacs.c
mv -f .deps/pinentry-emacs.Tpo .deps/pinentry-emacs.Po
make[2]: * No rule to make target ../assuan/libassuan.a', needed by pinentry-
emacs'. Stop.
make[1]: * [all-recursive] Error 1
make: *** [all] Error 2
------------8<----------------------------

I myself don't use emacs, but probably there are some OSX users who'd want pinentry-
emacs.

Looks to me like it just fails silently.

chdiza: Thanks for your help! I'm sorry about the confusion. I overlooked your
previous message. I've change pinentry-curses to recognize 0xf7 (127) as
backspace (6ce1d0c curses: Recognize ASCII DEL as backspace.) If this change
didn't fix the issue, please reopen.

Thanks for this report: you are absolutely right, we need to check if the actual
secret service is usable and not only if the library is available.

How exactly does pinentry fail? Does it just silently fail to save the
password? Does it still return the entered password to gpg-agent?

Thanks.

Can you still try building with the supplied patch and sending me the scancodes

for delete.

Sorry, I don't understand. I did build with the supplied patch, as I reported below,
and I included the output of /tmp/pinentry-curses-output.txt as instructed.

If get back as far as 0.9.1 and the bug is still present, then it wasn't
introduced by recent changes. That's good to know.

Can you still try building with the supplied patch and sending me the scancodes
for delete.

Thanks.

I attempted to bisect, but when I when back to version 0.8.1, I could not build. I get
stuff I don't understand and don't know how to fix, like:

config.status: error: cannot find input file: `gtk/Makefile.in'

And other stuff that seems related to older checkouts needing different versions of
autoconf/automake. I simply don't have the expertise to deal with that, or the time to
curate multiple versions of autotools. So I can't git bisect.

I did however find that the oldest release version of pinentry that I could build on my
system was 0.7.1, and it also had broken backspace/delete/whatever.

I also tried on OSX 10.5.8, same thing.

I suspect pinentry was always broken on OSX.

It sounds like you are missing some build dependencies. Perhaps something

related to iconv?

Well, I don't know. I'm not a programmer. I am not missing any deps when I build the
released versions of pinentry. I don't know what's different about the git repo
versions.

I made sure gettext was in my path and tried again, having applied your patch. It
compiled.

I then followed your original instructions. I typed:

onetwo<the-key-called-Delete-on-Mac>

and hit OK.

The contents of pinentry-curses-output.txt was:
6f
6e
65
74
77
6f
7f

Needless to say, "backspacing" still failed.

It sounds like you are missing some build dependencies. Perhaps something
related to iconv?

Looking at the keyboard, that appears to be the backspace key. (The last Mac I
used was an Apple 2E in school.) The backspace key works fine for me and I
don't have access to a Mac to debug the issue, so I'm going to need help. It
would be great if you could get pinentry to compile and used git bisect to find
the change that caused the problem (I'm assuming that the bug didn't exist at
some point).

Thanks.

The delete key never did anything, because the cursor is always at the end of

the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

I mean the key which has the word "delete" on it, as seen in the gallery here:
https://www.apple.com/keyboard/. It is in the same spot, and is labeled "delete",
on all Mac keyboards, not just the model shown in that gallery. They key in
question is the one that Mac users press to simultaneously back up the cursor and
delete whatever char was in the arrive-at position.

Probably now someone will tell me that the key is improperly labeled by Apple :)

The delete key never did anything, because the cursor is always at the end of

the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

I had to clone the git repo first. Once there, I applied the patch and I ran
autogen.sh. I can't get the resulting configure script to work. Both "./configure"
and "./configure --enable-maintainer-mode" result in the following:

---8<-----------------------------------
checking for ncursesw... no
checking for ncurses... no
checking for initscr in -lncursesw... no
checking for initscr in -lncurses... yes
checking for ncurses include dir... none
./configure: line 8466: syntax error near unexpected token `iconv'
./configure: line 8466: ` AC_LIB_LINKFLAGS_BODY(iconv)'
---8<-----------------------------------

D313: 647_0001-Add-debuging-output.patch

The delete key never did anything, because the cursor is always at the end of
the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

Please apply the following patch. The run: build-dir/curses/pinentry-curses and
type getpin. You'll be prompted for a pin. Type in some text and then press
"delete". Then please reply to this issue with the exact text that you typed
and the file /tmp/pinentry-curses-output.txt

Thanks.

Just checked:

  /* Reset the pinentry (in case of popup messages). */
  agent_reset_query (ctrl);

Thus the pinentry is only closed if it is used as a simple popup winode (e.g.
"Insert card with serial number xxx") but not for a regular Pinentry.

Actually there should be no need for gpg to notigy gpg-agent and thus pinentry
about a Ctrl-C. Due to Ctrl-C the gpg process dies and thus the connection to
gpg-agent receives an EOF/SIGPIPE and gpg-agent will shuot it down. Thus the
connection cleanup handler of gpg-agent needs to kill an open pinentry - I
tought this is already done.

Or is it the case that gpg does not see the Ctrl-C?

Hi Brian,

I tried it in PuTTY without screen and it was not skewed. The line draw
characters looked funny (which I'm assuming is a Unicode thing), but they
were in a rectangle.

bjmgeek: ping

I've now applied the patch.

ah, right! the other option is to pass mb->size instead of size in the memset call.

We should really synchronize secmem.c between libgcrypt:src/secmem.c,
pinentry:secmem/secmem.c, and gpg-STABLE-BRANCH-1-4:util/secmem.c :/

D305: 627_0001-secmem-When-clearing-memory-don-t-clear-beyond-the-e.patch

Well, that's embarrassing. It looks like it was my bug. The attached patch
seems to fix the problem.