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.

dkg: The problem is that the underlying architecture is broken. Unix's stock
permission model is about protecting users from other users, not protecting
processes from other processes. Thus, I don't think it makes any sense to
complicate the code by implementing these effectively useless protections.

FWIW, a widely used practical system that does a much better job at this is
Android. Android runs every program under its own uid. We could do the same
thing with gpg-agent. In fact, this is currently possible with a little help
from ssh. Unfortunately, this requires a fair amount of work by the user to set
up. In particular, the user needs to create a secondary account. It would be
nice if distributions provided a simply way for an unprivileged user to allocate
additional uids, but this is probably a lot of work.

At Fri, 31 Jul 2015 10:27:04 +0000,
Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

Despite that the use of these 100 characters is not a proper way to protect a
private key, they may exceed the 255 characters if most of them are non-ASCII
and non-Latin-1. Most characters of the latter are endoded with just 2 bytes in
UTF-8.

Thanks for testing this!

Werner: I think there is a bit of confusion. The suggestion is not to up the
998 character lmiit, but the pinentry-qt limit of 256. Rereading my note that
was probably not clear.

Also, the long password that SlipperyCow is talking about is about 100 characters.

The Assuan protocol limits the length to 998 characters. But, sure,
we can up the limit.

To be clear: pinentry passes the passphrase back to GPG Agent using Assuan.
Assuan has a line limit length of 1000 characters. This means that passwords
upto 998 characters should be okay. Can you please tell me how many characters
long your password is? Thanks!

Hi,

I just tried:

  echo | gpg2 -s > /dev/null

using an 80 character password. This correctly signed the message. I used
GnuPG from git and pinentry from git. I configured gpg-agent to use
pinentry-qt4. So unfortunately, I can't reproduce the problem (yet).

Neal

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.

Hi,

I think having a different agent for different values of GNUPGHOME is correct
behavior. It is desirable as it increases isolation.

What version of GnuPG are you using? (You filed this bug report against
libgcrypt.) Did you build from source? What distribution?

Thanks.

I don't know what you mean by "documented the issue". The best thing to do is
to report the bug in the KGpg or Fedora bug tracker.

Thanks for the feedback. Closing.

Thanks for doing this. Unfortunately, It seems that you don't have fully
debuging symbols. Can you please at least recompile Assuan with debugging
symbols so that the backtrace includes filenames and line numbers. Thanks!

Also: feel free to add the link to this issue and if it does turn out to be a
problem with GnuPG add any information here. Thanks!

Thanks for the report. We're not upsteam for KGpg and neither I nor Werner use
Fedora, which makes this issue difficult to debug. Can you please file a bug
report in Fedora's tracker? Thanks.

At Thu, 16 Jul 2015 11:52:04 +0000,
SlipperyCow via BTS wrote:

SlipperyCow <slipperycow@privatdemail.net> added the comment:

Hi Neal,

On Gentoo Hardened, 2.0.26 + libgcrypt 1.5.4 is installed.

On Debian 8, 2.0.26 + libgcrypt 1.6.3 is installed.

GnuPG works on both of those operating systems when using long passphrases.

Did something change in the 2.1.5 code that impacted, or restricted, acceptable
passphrase length?

One more question: on the other systems that do work with long passphrases, are
you also using 2.1.5? Thanks.

Thanks for researching this. We'll take a look at this soon. I'm confused
about whey you didn't just add this to T1878. Is this a separate issue?
Thanks.

Thanks for this report. I've applied a fix
(f2ee673c99825d5189631031ddec2dbf54dbd482) to HEAD and it will be in the next
release.

Also, compression will likely be removed from future versions of OpenPGP (RFC
4880 bis). There are three justifications. Removing compression simplifies
packet processing, which is good for security. OpenPGP is an encryption
standard not a compression standard and not including it doesn't preclude the
user from compressing the data anyway. It's a security risk, because
"compression provides an oracle for the plaintext" (see [1] and [2]).

[1] http://cryptopals.com/sets/7/challenges/51/
[2] https://www.ietf.org/mail-archive/web/openpgp/current/msg07718.html

Since you have a corefile, you probably have debugging symbols. Could you just
attach gdb and get a backtrace? Thanks!

gdb `which gpg-connect-agent`
run 'getinfo version' /bye

I'm not sure that 208k is much bigger than 196k. What is likely going on is
that gpg is using different compression parameters from zip.

I just tried using the Fedora 22 live cd, but it causes a kernel panic when
booting under qemu. I don't know what the problem is and don't have time right
now to debug it or install a full Fedora system. As such, I'd appreciate any
help that you can give. Thanks!

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?

Closing as requested. Thanks for taking time to bring a potential issue to our
attention!

Thanks for your detailed bug report. If I've understood correctly, the long
password problem only occurs on Fedora 22 and not on other systems that you've
tried.

Can you please provide me with a bit more information. Please take enigmail
out of the loop by running:

  echo | gpg -s >/dev/null

and

  echo | gpg2 -s >/dev/null

(assuming gpg and gpg2 are different binaries, which is normally the case).

Then, please tell me the OS, the version of gpg (gpg --version), the version of
pinentry (pinentry --version) and whether you got the error. I'm primarily
interested in Fedora 22, since this is where you observe the error.

Thanks for your help.

This shouldn't be a problem. Note: this type of question is better asked on the
gnupg-users mailing list.

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

Removing non-breaking spaces is a regression. Their appropriate use improves
readability. See, for instance, the following discussion:
https://tex.stackexchange.com/questions/15547/when-should-i-use-non-breaking-space
. If you have patches to improve the use of non-breaking spaces (adding them
where appropriate and removing them when they aren't as per the above), these
would be welcome.

As far as I can tell, this output shouldn't really be parsed anyways: it's only
intended for humans. Please feel free to ask on gnupg-devel how to
appropriately do what you are trying to do.

Thanks.

You say that this creates all kinds of problems, but you one cite one case,
which is a fixed bug in zsh. Can you give me a few more examples so that I can
better understand the problem and decide on the best solution. Thanks.

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

I've now pushed my version of this patch.

I've now pushed this patch.

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.

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.

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.

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.

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.

Werner:

The primary issue here isn't whether the dialogs should be model, but whether
they require the immediate attention of the user. Messages that don't require
the user's immediate attention should be shown asynchronously as notifications.
One-button dialogs are generally notifications, since they don't actually give
the user any choice. If a one-button dialog does require a synchronous
interaction then it is probably a bug.

Consider the bad passphrase case (and let's ignore the rest, since they are not
relevant to this issue). If we are not enforcing passphrase constraints and the
user enters a bad passphrase, then it makes sense to show a dialog. The user
has two options: "Enter a new passphrase" and "Take this one anyway"; GnuPG
needs more information from the user before it can continue.

If we are enforcing the passphrase constraints, then we currently show a dialog
with a single option: continue. The dialog is informational. However, the
dialog can't be shown as a notification: the user needs to know why he or she
needs to redo the enter-a-new-passphrase step. A background notification is
insufficient. The assertion is that this is actually a bug. This information
can be better shown in the enter passphrase dialog. That's exactly what this
patch does.

Do you agree with this reasoning? Can I apply this patch?

Thanks,

Neal

I narrow this down to commit: 23d2ef83cda644c6a83499f9327350d3371e8a17
Author: Werner Koch <wk@gnupg.org>
Date: Wed May 20 16:13:55 2015 +0200

agent: Cleanup caching code for command GET_PASSPHRASE.

* agent/command.c (cmd_get_passphrase): Read from the user cache.
--

We used to read the passphrase with mode CACHE_MODE_NORMAL but we put
it into the cache with CACHE_MODE_USER.  However, agent_get_cache does
not yet distinguish between them and thus this does not change
anything.

I traced agent/cache.c:agent_get_cache. The entry is in the cache, but its
cache_mode (CACHE_MODE_ANY) does not match cache mode (CACHE_MODE_USER) and thus
the password is not used:

  p *thecache
  $10 = {next = 0x0, created = 1434627188, accessed = 1434627188, ttl = -1, 
    pw = 0x7f94b4001d80, cache_mode = CACHE_MODE_ANY, key = "2"}

  (gdb) p !strcmp (r->key, key)
  $15 = 1
  (gdb) p r->pw
  $16 = (struct secret_data_s *) 0x7f94b4001d80
  (gdb) p ((cache_mode != CACHE_MODE_USER && cache_mode != CACHE_MODE_NONCE) ||

r->cache_mode == cache_mode)

$17 = 0

Werner:

Some brief background: the Gnome people want one-button confirmations to appear
as notifications, which can be dismissed asynchronously. This patch changes the
passphrase constraint violation 1-button confirmation (when
enforce-passphrase-constraints is set in gpg-agent.conf), which should be
displayed as a synchronous dialog, to instead be an error text displayed with
the next password prompt. Independent of what one thinks of notifications, I
think this change is a usability improvement.

D311: 644_0001-Show-passphrase-constraints-errors-as-password-promp.patch

A few comments:

The special casing is take_this_one_anyway2 is wrong. Instead, in
check_passphrase_constraints, if failed_constraints is not NULL, we just
shouldn't call check_passphrase_constraints.

You also removed a translation.

You didn't update the copyright year.

You didn't include a signed-off-by line.

I've created a new patch.

D310: 640_0001-Don-t-raise-max-cache-ttl-to-default-cache-ttl.patch

The attached patch fixes this problem, by not adjusting opt.max_cache_ttl or
opt.max_cache_ttl_ssh. Okay to apply?

I've now pushed this to master.

D300: 639_0001-Don-t-prompt-for-the-password-multiple-times-in-pine.patch

The attached patch forces opt.passphrase_repeat to 0 if we are in pinentry
loopback mode.