D312: 643_0001-Show-passphrase-constraints-errors-as-password-promp.patch

Sorry not giving you more details at first time. Actually I'm using
gpg-preset-passphrase.
Executing the steps you mentioned works for me as well. The problem seems to be
when gpg-preset-passphrase is used.

$ gpg-connect-agent 'getinfo version' /bye

D 2.1.5

OK

$ echo "asd"|/usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXXXXXX

$ gpg-connect-agent 'GET_PASSPHRASE --no-ask XXXXXXXXXX a a a' /bye
ERR 67108922 No data <GPG Agent>

-------

$ gpg-connect-agent 'getinfo version' /bye

D 2.1.4

OK

$ echo "asd"|/usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXXXXXX

$ gpg-connect-agent 'GET_PASSPHRASE --no-ask XXXXXXXXXX a a a' /bye
OK 617364

Distro: Archlinux 64bit

Followup details about XDG_RUNTIME_DIR if you're not familiar, see:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

"$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-
essential runtime files and other file objects (such as sockets, named pipes,
...) should be stored. The directory MUST be owned by the user, and he MUST be
the only one having read and write access to it. Its Unix access mode MUST be
0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST
be created when the user first logs in and if the user fully logs out the
directory MUST be removed. If the user logs in more than once he should get
pointed to the same directory, and it is mandatory that the directory continues
to exist from his first login to his last logout on the system, and not removed
in between. Files in the directory MUST not survive reboot or a full logout/login
cycle.

The directory MUST be on a local file system and not shared with any other
system. The directory MUST by fully-featured by the standards of the operating
system. More specifically, on Unix-like operating systems AF_UNIX sockets,
symbolic links, hard links, proper permissions, file locking, sparse files,
memory mapping, file change notifications, a reliable hard link count must be
supported, and no restrictions on the file name character set should be imposed.
Files in this directory MAY be subjected to periodic clean-up. To ensure that
your files are not removed, they should have their access time timestamp modified
at least once every 6 hours of monotonic time or the 'sticky' bit should be set
on the file.

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement
directory with similar capabilities and print a warning message. Applications
should use this directory for communication and synchronization purposes and
should not place larger files in it, since it might reside in runtime memory and
cannot necessarily be swapped out to disk."

Done with commit 010d26a for 2.1.6

In valgrind it did not crash. The keylisting exited normally. But showed several
errors.

Attached is the valigrind log.

You need to to set SSH_AUTH_SOCK yourself. See the example section in the
gpg-agent man page.

I will consider to print a warning.

Can you start dirmngr under valgrind?

gpgconf --kill dirmngr
valgrind --log-file=vg.log dirmngr --daemon --homedir /my/gnupg/home/dir

I've compiled current master and it works for the testcase. But when I start
kleopatra and it runs the keylist/verify dirmngr now crashes.

Can be triggered with gpgme: run-keylist --validate --cms

It crashes at different points but it never gets through all my certificates.

An example of the debug output that is collected before it crashes (differs
between crashes):

2015-06-16 19:09:15 dirmngr[9303.1] no CRL available for issuer id
18F071EAAC08885C9434A7DE1DB3AFC30F27DD32
2015-06-16 19:09:15 dirmngr[9303.1] DBG: chan_1 -> INQUIRE SENDCERT
2015-06-16 19:09:15 dirmngr[9303.1] DBG: chan_1 <- [ 44 20 30 82 04 7d 30 82 03
65 a0 03 02 01 02 02 ...(982 byte(s) skipped) ]
2015-06-16 19:09:15 dirmngr[9303.1] DBG: chan_1 <- [ 44 20 14 34 6d f5 07 c2 04
86 4a ba a1 71 50 b0 ...(187 byte(s) skipped) ]
2015-06-16 19:09:15 dirmngr[9303.1] DBG: chan_1 <- END
2015-06-16 19:09:15 dirmngr[9303.1] checking distribution points
2015-06-16 19:09:15 dirmngr[9303.1] no distribution point - trying issuer name
2015-06-16 19:09:15 dirmngr[9303.1] fetching CRL from default location
2015-06-16 19:09:15 dirmngr[9303.1] ldap wrapper 10199 started (reader
0x00007f6a580337a0)
2015-06-16 19:09:15 dirmngr[9303.0] ldap wrapper 10198 ready: exitcode=1
2015-06-16 19:09:15 dirmngr[9303.0] ldap worker stati:
2015-06-16 19:09:15 dirmngr[9303.0] c=0x00007f6a58033740 pid=10199/10199
rdr=0x00007f6a580337a0 ctrl=0x00007f6a580008c0/1 la=1434474555 rdy=0
2015-06-16 19:09:15 dirmngr[9303.0] c=0x00007f6a58022520 pid=-1/10198
rdr=0x0000000000000000 ctrl=0x0000000000000000/0 la=1434474554 rdy=1
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10199]: processing url 'ldap://'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10199]: host
'directory.verisign.com'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10199]: port 389
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10198]: processing url 'ldap://'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10198]: host
'directory.verisign.com'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10198]: port 389
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10199]: DN
'1.2.840.113549.1.9.1=#4865696E65636B656E40676D61696C2E636F6D,CN=Common
Name,ST=Some-State,C=DE'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10199]: filter
'objectClass=*'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10199]: attr
'certificateRevocationList'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10198]: DN
'1.2.840.113549.1.9.1=#4865696E65636B656E40676D61696C2E636F6D,CN=Common
Name,ST=Some-State,C=DE'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10198]: filter
'objectClass=*'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10198]: attr
'certificateRevocationList'
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10198]: searching 'ldap://'
failed: No such object
2015-06-16 19:09:15 dirmngr[9303.0] ldap worker stati:
2015-06-16 19:09:15 dirmngr[9303.0] c=0x00007f6a58033740 pid=10199/10199
rdr=0x00007f6a580337a0 ctrl=0x00007f6a580008c0/1 la=1434474555 rdy=0
2015-06-16 19:09:15 dirmngr[9303.0] c=0x00007f6a58022520 pid=-1/10198
rdr=0x0000000000000000 ctrl=0x0000000000000000/0 la=1434474555 rdy=1
2015-06-16 19:09:15 dirmngr[9303.0] dirmngr_ldap[10199]: searching 'ldap://'
failed: No such object
2015-06-16 19:09:15 dirmngr[9303.0] ldap wrapper 10199 ready: exitcode=1
2015-06-16 19:09:15 dirmngr[9303.0] ldap worker stati:
2015-06-16 19:09:15 dirmngr[9303.0] c=0x00007f6a58033740 pid=-1/10199
rdr=0x0000000000000000 ctrl=0x00007f6a580008c0/1 la=1434474555 rdy=1

Backtrace for this log (also differs):

#0 0x00007f6a69109cc9 in GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f6a6910d0d8 in GI_abort () at abort.c:89
#2 0x00007f6a69146394 in __libc_message (do_abort=do_abort@entry=1,

fmt=fmt@entry=0x7f6a69254b28 "*** Error in `%s': %s: 0x%s ***\n") at

../sysdeps/posix/libc_fatal.c:175
#3 0x00007f6a6915266e in malloc_printerr (ptr=<optimized out>,
str=0x7f6a69254cf0 "double free or corruption (fasttop)", action=1)

at malloc.c:4996

#4 _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3840
#5 0x00007f6a69d4fd2d in ?? () from /opt/gnupg/lib/libgcrypt.so.20
#6 0x0000000000428802 in ldap_wrapper (ctrl=ctrl@entry=0x7f6a580008c0,
reader=reader@entry=0x7f6a64c05cd0,

argv=argv@entry=0x7f6a64c05a80) at ldap-wrapper.c:772

#7 0x000000000042218c in run_ldap_wrapper (ctrl=ctrl@entry=0x7f6a580008c0,
multi_mode=multi_mode@entry=0, proxy=0x0,

host=<optimized out>, port=<optimized out>, user=<optimized out>, pass=0x0, 
dn=dn@entry=0x7f6a58001d50

"1.2.840.113549.1.9.1=#4865696E65636B656E40676D61696C2E636F6D,CN=Common
Name,ST=Some-State,C=DE",

filter=filter@entry=0x44dcc1 "objectClass=*", attr=attr@entry=0x44b50a

"certificateRevocationList", url=url@entry=0x0,

reader=reader@entry=0x7f6a64c05cd0, ignore_timeout=0) at ldap.c:191

#8 0x00000000004228ea in attr_fetch_ldap (ctrl=0x7f6a580008c0,

dn=0x7f6a58001d50

"1.2.840.113549.1.9.1=#4865696E65636B656E40676D61696C2E636F6D,CN=Common
Name,ST=Some-State,C=DE",

attr=attr@entry=0x44b50a "certificateRevocationList",

reader=reader@entry=0x7f6a64c05cd0) at ldap.c:287
#9 0x0000000000414aed in crl_fetch_default (ctrl=ctrl@entry=0x7f6a580008c0,

issuer=issuer@entry=0x7f6a58001d50

"1.2.840.113549.1.9.1=#4865696E65636B656E40676D61696C2E636F6D,CN=Common
Name,ST=Some-State,C=DE", reader=reader@entry=0x7f6a64c05cd0) at crlfetch.c:319
#10 0x000000000041439d in crl_cache_reload_crl (ctrl=ctrl@entry=0x7f6a580008c0,
cert=0x7f6a58002740) at crlcache.c:2554
#11 0x000000000040e1d5 in inquire_cert_and_load_crl (ctx=0x7f6a58000950) at
server.c:589
#12 cmd_isvalid (ctx=0x7f6a58000950, line=<optimized out>) at server.c:901
#13 0x00007f6a6a23e96a in ?? () from /opt/gnupg/lib/libassuan.so.0
#14 0x00007f6a6a23ed49 in assuan_process () from /opt/gnupg/lib/libassuan.so.0
#15 0x000000000040edc7 in start_command_handler (fd=fd@entry=1) at server.c:2243
#16 0x000000000040ada5 in start_connection_thread (arg=arg@entry=0x1) at
dirmngr.c:1937
#17 0x00007f6a69908dbc in thread_start (startup_arg=<optimized out>) at npth.c:265
#18 0x00007f6a696f1182 in start_thread (arg=0x7f6a64c06700) at pthread_create.c:312
#19 0x00007f6a691cd47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

A different backtrace:

#0 0x00007fe9e9805cc9 in GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007fe9e98090d8 in GI_abort () at abort.c:89
#2 0x00007fe9e9842394 in __libc_message (do_abort=do_abort@entry=1,

fmt=fmt@entry=0x7fe9e9950b28 "*** Error in `%s': %s: 0x%s ***\n") at

../sysdeps/posix/libc_fatal.c:175
#3 0x00007fe9e984dac2 in malloc_printerr (ptr=<optimized out>,
str=0x7fe9e994cbfc "corrupted double-linked list", action=1)

at malloc.c:4996

#4 malloc_consolidate (av=av@entry=0x7fe9d8000020) at malloc.c:4165
#5 0x00007fe9e984edf8 in _int_malloc (av=0x7fe9d8000020, bytes=1025) at
malloc.c:3423
#6 0x00007fe9e98517b0 in GI_libc_malloc (bytes=1025) at malloc.c:2891
#7 0x00007fe9ea44ad11 in ?? () from /opt/gnupg/lib/libgcrypt.so.20
#8 0x00007fe9ea44bc19 in ?? () from /opt/gnupg/lib/libgcrypt.so.20
#9 0x00007fe9ea93b284 in init_membuf (maxlen=0, initiallen=<optimized out>,
mb=0x7fe9e53018e0, ctx=0x7fe9d8000950)

at assuan-inquire.c:64

#10 assuan_inquire (ctx=ctx@entry=0x7fe9d8000950, keyword=keyword@entry=0x44774b
"SENDCERT",

r_buffer=r_buffer@entry=0x7fe9e5301d50,

r_length=r_length@entry=0x7fe9e5301d60, maxlen=maxlen@entry=0) at
assuan-inquire.c:169
#11 0x000000000040dfca in inquire_cert_and_load_crl (ctx=0x7fe9d8000950) at
server.c:567
#12 cmd_isvalid (ctx=0x7fe9d8000950, line=<optimized out>) at server.c:901
#13 0x00007fe9ea93a96a in dispatch_command (ctx=0x7fe9d8000950, line=<optimized
out>, linelen=<optimized out>)

at assuan-handler.c:675

#14 0x00007fe9ea93ad49 in process_request (ctx=0x7fe9d8000950) at
assuan-handler.c:871
#15 assuan_process (ctx=0x7fe9d8000950) at assuan-handler.c:894
#16 0x000000000040edc7 in start_command_handler (fd=fd@entry=6) at server.c:2243
#17 0x000000000040ada5 in start_connection_thread (arg=arg@entry=0x6) at
dirmngr.c:1937
#18 0x00007fe9ea004dbc in thread_start (startup_arg=<optimized out>) at npth.c:265
#19 0x00007fe9e9ded182 in start_thread (arg=0x7fe9e5302700) at pthread_create.c:312
#20 0x00007fe9e98c947d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Sorry, I can't replicate this. First I enter "123" as passphrase
using

  $ gpg-connect-agent 'GET_PASSPHRASE  XXXXXXXXXX a a a' /bye
  OK 616263

Then I ask for it with --no-ask

  $ gpg-connect-agent 'GET_PASSPHRASE --no-ask XXXXXXXXXX a a a' /bye
  OK 616263

Now let's delete it from the cache:

  $ gpgconf --reload gpg-agent

and ask again:

  $ gpg-connect-agent 'GET_PASSPHRASE --no-ask XXXXXXXXXX a a a' /bye
  ERR 67108922 No data <GPG Agent>
  OK

I am using

  $ gpg-connect-agent 'getinfo version' /bye
  D 2.1.6-beta3

but that did not changed things in this part of GnuPG.

Fixed with commit be34857.

PGP-2 fingerprints are enabled again but a warning is printed. There is no need
to reject the signature because the key itself maybe valid if it uses non-MD5
self-signatures. GUIs however should detect a 16 byte fingerprint and also
print an appropriate warning.

Weel, your patch defeated the code to properly log all output from the ldap
helper and only then cleanup the wrappers. For the actual fix please see T1978.

Fixed with commit 685b782.

Duplicate of T1978

Well, there was the ldap-reaper thread still running and due to a bug in the log
output handing code it was not able to remove its context structures and thus it
kept on spinning.

Fixed with commit 685b782.

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.

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?

Fixed in 2.1.3.

Fixed in 2.0.28 (and in 2.1.x).

D309: 638_scd-add-zero.diff

Thank you for your testing.
For in-stock CCID driver, could you please test this patch?
For PC/SC, I'm going to investigate the issue.

(1) pinpadtest.py with no option works? Prompt on the reader? And you can input PIN?

The padlock LED on the reader blinks and I enter the pin. When I press
the green return button on the reader, the traceback is shown.
Also the PIN retry counter is decremented (which was quite a cavecat for
debugging)

Fixed in master which was released as 2.1.5.
Fixed in the repo of 1.4 and 2.0.

Hm, you make a good point about this being undesirable in the general case --
access to a normal gpg-agent shouldn't provide an attacker with a way to guess
passwords silently.

However, consider the mailpile case -- where gpg-agent is running on the
webserver, and the login webpage wants to verify a given user based on the
password for the user's secret key (and wants to avoid keeping some extra
/etc/shadow-equivalent file lying around).

Maybe such an application would start gpg-agent in a different/simpler mode? Or
should we recommend that such an application test the provided passphrase in
some other way, without using gpg-agent at all?

Does encrypt-to/hidden-encrypt-to in gpg.conf do this?

This feature has landed in the latest 2.0 and 2.1 branches and support has been
added in pinentry. I'm closing this now.

Hi dkg,

On the mailing list and in T1928, we discussed
why it shouldn't be possible for a program to pass the passphrase to gpg agent.
This feature request is at odds with the conclusion drawn there. Should this
issue be closed as WONTFIX?

Thanks,

:) Neal

Hi, thomai,

Please run something like the following:

  echo | gpg2 --sign

Does gpg2 complain the the connection to gpg agent was hijacked? If so, please
disable GNOME Keyring and try to reproduce the problem.

If the problem continues to exist, can you tell me approximately how long your
password is?

Thanks,

Neal

Let's confirm facts.
(1) pinpadtest.py with no option works? Prompt on the reader? And you can input PIN?
(2) Or else, pinpadtest.py --add works?
(3) When (1) and (2) fail, pinpadtest.py --pinmin 6 --pinmax 15 works?
(4) When (1), (2), and (3) fail, pinpadtest.py --pinmin 6 --pinmax 15 --add works?

I'm pretty sure that the reader supports varlength pinpad input - it is the same
device that was used here: T1549

asdil12 <dominik@heidler.eu> added the comment:

Same error when using gnupg's CCID.

Thank you for testing.

Same error when using gnupg's CCID.

$ ./pinpadtest.py
Reader/Token: Cherry GmbH SmartTerminal ST-2xxx [Vendor Interface] (000004fa) 00 00
ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
Please input User's PIN
Traceback (most recent call last):

File "./pinpadtest.py", line 378, in <module>
  main(who, method, add_a_byte, pinmin, pinmax, change_by_two_steps, fixed)
File "./pinpadtest.py", line 242, in main
  card.cmd_verify_pinpad(who)
File "./pinpadtest.py", line 138, in cmd_verify_pinpad
  raise ValueError, ("cmd_verify_pinpad %02x %02x" % (sw1, sw2))

ValueError: cmd_verify_pinpad 69 82

When you are using PC/SC service and Python and pyscard works
well on your system, please try my pinpadtest.py script.

Done with commit 25331bb for 2.1.5.
Won't be backported to 2.0 or 1.4.

This also changes the publication date to the date of the last commit for one of
the texi files. This was the original intention of the version.texi file but
that did not worked in a git world.

Thank you for your registering an issue at BTS.

Fixed with commit 255dadd.

This also extends to keys stored on smartcards, see
https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/029959.html

Won't be done for 2.0 but I will try to implement that for 2.1

On Monday 08 June 2015 at 12:50:23, Werner Koch via BTS wrote:

Workaround: --allow-weak-digest-algos

Workaround: --allow-weak-digest-algos

But I agree that this is not a good option. We better reject the signature.

GnuPG takes the passphrase as a verbatim string of bytes. It does not do any
recoding. I have not looked into the deatils why this is not working for you.

The workround is to use "gpg --passwd" on the old system to change the
passphrase to ascii-only, switch to the other system, and if you want change the
passphrase again.

FWIW: The PKCS#12 import of gpgsm has a similar problem. There is no agreeement
on how passphrases are encoded and thus all tools do whatever they like. To
mitigate that gpgsm has a list of common encodings and on import failure it
tries using a different encoding. If that encoding problem on gpg evolves into
a common problem, we might build a tool which tries to re-encrypt a passphrase.

How would the suggested method of programmatically using gpg be?

I'm maintaining a service that uses gpg as a streaming encryption/decryption
backend and we need to provide the passphrase for the keys somehow in a
convenient manner.

Priming the agent is not optimal too because it would force me to restart the
agent every time i add new keys.

Maybe give me the possibility to provide new passphrases to the agent via the
agent socket?

In another message (<874mnnlqxn.fsf@alice.fifthhorseman.net>) DKG notes that we
shouldn't allow loopback mode or preseeding to prevent passphrase-guessing attacks.

D306: 630_0001-gpg-Avoid-cluttering-stdout-with-trustdb-info-in-ver-STABLE-1-4.patch

And here is a backport to STABLE-BRANCH-1-4