Right. Hopefully fixed with 48ab8cd

I wonder why this worked for me. If I try to run your testcase it fails with
bash / dash / zsh.

Thanks, but I'm afraid that's not sufficient; the issue of the whitespace after
have_qt5_libs still exists after that commit for bash.

See the following test case: $ cat ./test.sh
#!/bin/bash
have_qt5_libs="no";
echo ${have_qt5_libs}

have_qt5_libs2 = "no";
echo ${have_qt5_libs2}

$ ./test.sh
no
./test.sh: line 5: have_qt5_libs2: command not found

The good news is that besides this buglet I've now pushed the updated revision
to our testing repository and have yet to get any bug reports. The patch I've
pushed is
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/pinentry/files/pinentry-0.9.6-add-disable-pinentry-qt5-option.patch#n38
which doesn't experience this issue.

I've fixed the variable assignment with rev. e9d063e
Sorry. Worked for me on debian jessie with dash.

"+ have_qt5_libs = no;" result in command not found issues in configure so I
changed this to "+ have_qt5_libs="no";".

I've done some preliminary packaging tests and things seems to be working as
expected, will give it some more local testing before pushing it onto users in
testing

Thank you, that is exactly the kind of mechanism I was looking for. I'll give it
a try to packaging over the next few days.

The rationale behind this was that it should just compile with Qt > 4.4 and take
the newest version available. But yes with Qt packaging in different names
between 4 and 5 etc. I can see that this can be problematic.

With: 08ec9556c8a384ea7bb5d42d3f6aab6c2f6a8786 I've added an option
"disable-pinentry-qt5" to explicitly disable looking for qt5.

Does this solve your problem?

ciil: Thanks for the update!

0.9.6 has meanwhile been released - any news?

0.9.6 has been released - does it work?

All of the pinentry's use the same metric, which is very naive. From
agent/call-pinentry.c:

/* Estimate the quality of the passphrase PW and return a value in the

range 0..100.  */

static int
estimate_passphrase_quality (const char *pw)
{

  int goodlength = opt.min_passphrase_len + opt.min_passphrase_len/3;
  int length;
  const char *s;

  if (goodlength < 1)
    return 0;

  for (length = 0, s = pw; *s; s++)
    if (!spacep (s))
      length ++;

  if (length > goodlength)
    return 100;
  return ((length*10) / goodlength)*10;

}

Sorry for not having provided more information earlier. The bug seemed to only appear
on my work machine (and I've been to busy at work the last few weeks to provide more
information), but now I can reliably reproduce it on my home machine, too, funnily
enough after a clean re-install of Arch Linux.

It certainly seems to be the same bug as the Gentoo bug #560158 you linked. I cannot
reproduce the behavior in either gdb or valgrind, but without those the command fails
every time.

I've since downloaded and manually built 0.9.5 and 0.9.6. I could reproduce it in the
standalone 0.9.5 build (again, neither valgrind nor gdb could be coerced into also
showing the behavior. The issue seems to be fixed in 0.9.6, though! Arch doesn't yet
provide the new version as an official package. I'll tell you if the issue's also fixed
when that package comes out.

Still have no idea what caused it though.

Kristian Fiskerstrand pointed out that there is more information about this bug
at: https://bugs.gentoo.org/show_bug.cgi?id=560158

I am pretty sure this should be fixed with the current master version of pinentry.

This version does no longer use the std::string stuff as it uses the usual qt
widgets.

Feel free to reopen this bug but I am so sure about it that I'll mark it as
resolved now :-)

Hi Neal, you are right about the entropy. I tought it was gpg but I think it's
because my system is too minimal to produce enough entropy. I finally decided to
generate my keys in another machine and transfer them to my minimal
installation. Now it works perfectly, with pinentry 0.9.5.

Thanks for your help,

Regards,

Felix

I can't reproduce this. I'm using pinentry 0.9.5 and GnuPG from git. When I
generate a key, it talks nearly 3 minutes for GnuPG to gather the required
amount of entropy, but it eventually returns. Attaching to gpg-agent using gdb,
it appears that gpg-agent is "suck" in the generate key function:

  #9  0x00007f13a08da9ce in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.20
  (gdb) 
  #10 0x00007f13a08ca2db in gcry_pk_genkey ()
     from /lib/x86_64-linux-gnu/libgcrypt.so.20
  (gdb) 
  #11 0x000000000041f51f in agent_genkey (ctrl=0x1b69e80, cache_nonce=0x0, 
      keyparam=0x7f1398001e70 "(genkey(rsa(nbits 4:1024)))", keyparamlen=27, 
      no_protection=0, override_passphrase=0x0, preset=0, outbuf=0x7f139fccfdb0)
      at ../../../gnupg/agent/genkey.c:479
  479	  rc = gcry_pk_genkey (&s_key, s_keyparam );

So, I seriously doubt that this is a problem with pinentry. And also I doubt
that it is a problem with GnuPG. Most likely, you need to wait for the system
to generate more entropy.

If you think gpg or gpg-agent is really hung, it would be nice if you could use
gdb to attach and then get a backtrace and post that here.

Thanks!

Neal

Thanks for the report. I'm having trouble reproducing this. I run pinentry
(from the build directory) as follows:

  $ valgrind gtk+-2/pinentry-gtk-2
  ==3611== Memcheck, a memory error detector
  ==3611== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==3611== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
  ==3611== Command: gtk+-2/pinentry-gtk-2
  ==3611== 
  OK Pleased to meet you
  getpin
  D 012345678901234567890
  OK

I enter a 21 character password and pinentry doesn't crash and valgrind doesn't
report any error. I tried with both 0.9.5 and the latest version from git.

Are you able to reproduce the problem using the above method? Can you provide
an example of how to cause the crash using only pinentry?

Thanks.

Here is the content of my gpg-agent.conf:
debug-pinentry
log-file /home/fxleblanc/gpg-errors.txt
pinentry-program /usr/bin/pinentry-curses

Here is the content of my log file:
gpg: reading options from '/home/fxleblanc/.gnupg/gpg.conf'
gpg (GnuPG) 2.1.6; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat
trust hashing cardio ipc clock lookup extprog

gpg: signal Interrupt caught ... exiting

I interrupted the program because it wasn't doing anything after I entered my
passphrase.

--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