Thank you for your bug report.
Does attached gpg-agent-no-nls.diff works for you?

D314: 653_gpg-agent-no-nls.diff

Please check if the directory (of C:\GnuPG) permission is valid. Command would
be: dir C:\GnuPG
Please check if pubring.bak does not exist.

The fixes are included into 2.1.6.
Please test GnuPG 2.1.6.

In GnuPG 2.1.6, for GNU/Linux and FreeBSD with PC/SC service, I think that I've
fixed an issue related to "insufficient buffer" error. I also fixed a problem
of internal CCID driver for GNU/Linux and others (not for Windows).

In the error of your sc.log (on Windows), the card reader returns 6700, which
means "wrong length". I don't know well, why this happens. If it's by similar
cause, the change introduced in 2.1.6 would improve situation.

For PC/SC, it is confirmed with GemPCPinpad SmartCard Reader on Debian GNU/Linux.
Fix is applied to the development repo.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=5e1d2fe6555d06f9dcd2daac713b2edfbc0428a5

I believe that this fix finally resolves the issue.

On 06/19/2015 04:13 PM, asdil12 via BTS wrote:

For the pinpadtest script case (without the --add parameter) it actually asks
for the pin, but when I press enter to confirm, the retry counter is decremented
and the stacktrace is shown.

D308: 646_scd-change-st-2000-20150619.diff

I think that:
(1) When all correct, it works well (patched case)
(2) When it's mostly correct but problem with length, it doesn't work (no prompt
to user) and retry counter is decremented. (pinpadtest script case)
(3) When it's bad, it doesn't work and retry counter keeps its value (current gpg)

Here is current patch. This includes change for PC/SC.

On 06/17/2015 11:01 PM, Jeffrey Walton wrote:

I'm actually more concerned that the optimizer will remove the code
because it surmises its a dead store. That's the issue I am trying to
articulate.

Reading your report again, I found that it works on Tails, but not on Windows,
and the behavior is different between Windows 7 and Windows 8.1.
Which is somehow strange (for me).

Could you please test with following configuration?

• .gnupg/scdaemon.conf

debug-level guru
debug-all

log-file /tmp/scd.log

Please change the filename /tmp/scd.log.
Thank you for your cooperation.

Thank you for your auditing libgcrypt. Your effort helps our
development.

Thank you for clarification.

I think that JW had some confusion. I believe that his argument is irrelevant
for libgcrypt's implementation of wipememory.

(1) Ian is right about multi-processors and memory access. We should use atomic
operations, memory barrier, and mutual exclusion things like lock/unlock.
(2) Compiler can optimize away memory access if computation should be same (as
defined by the language).

libgcrypt's use of volatile qualifier for wipememory is *not* for shared access
by multi-processors.
It is to make sure memory is wiped by its write access.

Certainly, it's not "memory mapped hardware", and it would be abuse. But, this
interpretation does not conflict with current wipememory implementation. Write
access to memory mapped hardware never removed. For correctness of code, I
believe current implementation is OK.

If this were the suggestion for fast wipememory, I would agree for non-use of
volatile qualifier. I think that current implementation is OK, considering use
cases.

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.

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

Thanks for your report. Now, I'm handling a bug report for Cherry ST-2000U on
GNU/Linux. After it will be fixed, I'll look this in detail.

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?

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

Same error when using gnupg's CCID.

Thank you for testing.

The version string match bug was fixed in master and 1.6 branch.

Thank you, patch applied to master and 1.6 branch.

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

Thank you for your registering an issue at BTS.

Here is a possible fix.
I write this for current master branch and tested.
Then, it is ported to 1.4. It builds and it seems working well.
Please test it out.
I was wrong in T1675 (gniibe on May 15 2015, 06:38 AM / Roundup) saying multiple races.
Provided write(2) is atomic, the race is only here for creating trustdb.gpg and
checking if it's there.

D206: 619_gpg14-create-trustdb-race-fix.diff

BTW, I believe it would be better for Emacs to implement its own pinentry UI,
not using loopback mode.
I mean, something similar situation where we have emacsclient as an external editor.
If we have pinentry by Emacs, people will be able to invoke gpg on remote
machine and access local secret key by local gpg-agent which asks passphrase to
local Emacs's pinentry.

Currently, I don't know the solution. Here is some information, while I'd
understand your implied request.

With use-agent, the behavior is same between 1.4 and 2.1. 2.0 and 2.1 has
similar behavior (although it doesn't support loopback mode).
In 1.4, with cpr_enabled, it stops reading repeated input, which makes sense.

Fixed in b3fd30451a5464b124b0296afbc341cb98b3977c.

Now, we have a patch to fix in the Debian bug tracker.

It was fixed in 2.1.4.

On 05/13/2015 11:13 PM, NIIBE Yutaka via BTS wrote:

I think that same bug is in 2.0 and 2.1, too.
I'll try to make minimal reproducible scenario to locate the bug.

Thank you for your time and cooperation.
Your data helps me a lot.
I think that same bug is in 2.0 and 2.1, too.
I'll try to make minimal reproducible scenario to locate the bug.

Please let us know your filesystem for .gnupg/ directory.
Unfortunately, I couldn't reproduce the bug with your script on my machine.
If possible, could we share the output of the script in your system?

I checked the code and the behavior. It is confirmed that the default of
gpg-agent disables loopback-pinentry mode and user needs to enable it.

Now, we need some fixes/improvements:
(1) gpg should automatically work with gpg-agent with the option of --passphrase
(-file, -fd).
In GnuPG 2.1.x, the secret keys are under control of gpg-agent and gpg frontend
should pass the passphrase to gpg-agent in some way.
When --passphrase (-file, -fd) option is supplied, gpg frontend could use
gpg-agent feature of either loopback-pinentry mode _OR_ preset_passphrase .
The latter requires specific key identification, so, loopback-pinentry mode
would be the solution for general.
(2) Both of loopback-pinentry mode and preset_passphrase are disabled as
default. We need to fix this default of gpg-agent _AND_ we need to fix gpg
frontend error handling of this case of disabled feature of gpg-agent. Well, I
don't know the reason this features need to be disabled...
(3) When it is gpg frontend which invokes gpg-agent, it would be natural to
enable loopback-pinentry (or preset_passphrase). But, there will be existing
gpg-agent even with --batch option. I don't know how it should work in this case.

Thanks for your further experiment. I didn't read well about the part of
'mkfifo' in your first message.
I think that you expect some interactive behavior; gpg emits NEED_PASSPHRASE
when its needed, and your program writes to the fifo.

No, gpg doesn't work like that with --passphrase-file or --passphrase-fd.
gpg will read the passphrase string from a file or an fd at the start.

Although the output timing of NEED_PASSPHRASE is different (than your
expectation), it is emitted after gpg reads passphrase string and it needs the
passphrase for signing.

It doesn't reproducible for me with 2.0.26 in Debian.
For 1.4, you need --no-use-agent when you have use-agent option in your
configuration.

It seems that your gpg-agent doesn't support loopback mode.
Either, your gpg-agent is from 2.0 or the socket is hijacked by gnome-keyring.
For the latter, please see http://wiki.gnupg.org/GnomeKeyring

It can be specified by scdaemon's option. Now in 2.0.x and 2.1.x, it does
partial match for PC/SC.
So, this issue is now closed.

It's fixed in 2.0.18 (as the T1203 was closed).

Confirmed that this is fixed in GnuPG in 2.0.25. In the external reference (the
bugzilla at RedHat), it's also closed already.
In the SCM (http://pkgs.fedoraproject.org/cgit/gnupg2.git), it's
1f6281e091d124170238821e7b9150ab56ff1195 which
removed the patch.

In 1.6.3, libgcrypt now work with automake >= 1.14.

See the commit: c123e313e90a6ffb14c9be3ddaab3ad44a44f2b6

In GnuPG 2.1.x, secret key is under control of gpg-agent. You can use
--pinentry-mode=loopback.
But, I think that --batch should imply --pinentry-mode=loopback.

I confirmed that it's in 2.0.x, too.
My patch is here:
http://lists.gnupg.org/pipermail/gnupg-devel/2015-April/029752.html

Thank you for the reproducible case.
This would be the cause my key becoming too big in someone's keyring.
I'm going to investigate in detail, for 1.4.x and 2.0.x.

Great.

FYI, the change for npth is committed.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=npth.git;a=commitdiff;h=c2015a2bafa99fdab8f26af9b60e93f1d36ac166

Thanks. No, you don't need to create another issue, since it's known simple issue.

Old system has clock_gettime function in librt. Please link with -lrt.
It would be good for npth's configure script to detect this for its build time.
I'll consider about that.

I mean, when you manually edit common/Makefile.in, you need to edit the variable
am__objects_18, so that it won't include the object generated by t-support.c.

On 04/23/2015 05:20 PM, Rainer Perske via BTS wrote:

no change: I had already tried installing from scratch working in an empty
directory.

Please show us the version of your gpg-agent and its configuration
(~/.gnupg/gpg-agent.conf).
The version of gpg-agent is usually expected to be same one of gnupg, and the
invocation is:

/opt/freeware/bin/gpg-agent --daemon /bin/<SOMESHELL> # to invoke subshell
or
/opt/freeware/bin/gpg-agent --daemon # to be background

GnuPG invokes gpg-agent with --use-standard-socket-p to check if gpg-agent exists,
but it seems your GnuPG failed here waiting finish of gpg-agent.

Umm... Could you try 'make distclean', then 'configure && make'? t-support.o is
not the target to build any more by the patch,
so, it should not be linked to t-stringhelp.
When you change common/Makefile.am and common/Makefile.in, common/Makefile
should be generated again,
but it would not be generated, perhaps.

Please try a patch:
http://lists.gnupg.org/pipermail/gnupg-devel/2015-April/029739.html

Here is error in dirmngr:

2015-04-22 09:23:41 dirmngr[3108.0] critical certificate extension 2.5.29.36 is
not supported
2015-04-22 09:23:41 dirmngr[3108.0] critical certificate extension 2.5.29.54 is
not supported
2015-04-22 09:23:41 dirmngr[3108.0] error checking validity of CRL issuer
certificate: Unsupported certificate
2015-04-22 09:23:41 dirmngr[3108.0] crl_parse_insert failed: Unsupported certificate
2015-04-22 09:23:41 dirmngr[3108.0] crl_cache_insert via DP failed: Unsupported
certificate
2015-04-22 09:23:41 dirmngr[3108.0] command 'ISVALID' failed: Unsupported
certificate
2015-04-22 09:23:41 dirmngr[3108.0] DBG: chan_0 -> ERR 167772263 Unsupported
certificate <Dirmngr>
2015-04-22 09:23:41 dirmngr[3108.0] DBG: chan_0 <- [eof]

Confirmed.
I imported Scott-Perry.p7b by gpgsm, which worked fine.
Then, invoking 'gpgsm --debug-all -r 0x085c2a5c --encrypt some.txt', it said:

gpgsm: certificate #08278A9EBB6B91E8587386AF2C312F99/CN=RAPIDGate PIV-I Agency
CA,O=Eid Passport\, Inc.,C=US
gpgsm: checking the CRL failed: Unsupported certificate
gpgsm: validation model used: shell
gpgsm: can't encrypt to '0x085c2a5c': Unsupported certificate

Please see T1930. And if you have time, please
test it for PC/SC.
For GnuPG's internal CCID driver, you can use reader-port=1 for the case of a).
I don't know if partial match will be useful for internal CCID driver.

D291: 599_gpg2-scd-issue-1930-patch.diff