t-stringhelp.c:428: test 2 failed
FAIL: t-stringhelp
PASS: t-timestuff
PASS: t-convert
PASS: t-percent
PASS: t-gettime
PASS: t-sysutils
PASS: t-sexputil

> Known envvars: GPG_TTY(ttyname) TERM(ttytype) DISPLAY(display)
> XAUTHORITY(xauthority) XMODIFIERS GTK_IM_MODULE DBUS_SESSION_BUS_ADDRESS
> QT_IM_MODULE INSIDE_EMACS PINENTRY_USER_DATA(pinentry-user-data)

PASS: t-session-env
PASS: t-openpgp-oid
PASS: t-ssh-utils
PASS: t-mapstrings
PASS: t-zb32
PASS: t-mbox-util
PASS: t-iobuf
PASS: t-strlist
PASS: t-private-keys
PASS: t-ccparray

PASS: t-exechelp

1 of 18 tests failed

Please report to https://bugs.gnupg.org

make: The error code from the last command is 1.

Stop.
make: The error code from the last command is 2.

Stop.
make: The error code from the last command is 2.

Stop.
make: The error code from the last command is 1.

Stop.

is there any way to get better debug output so this can be tracked down?

Thank you for the version information which worked.

Speaking of the code of scdaemon, there is no difference for unblocking (by
resetcode and by admin) between 2.1.11/12 and 2.0.30.

Please note that there are two subcommands.

    admin -> passwd -> 2: unblocking by Admin
    unblock: unblocking by resetcode

Latter requires setting resetcode beforehand.

This was possible on my mac with:

gpg (GnuPG) 2.0.30
libgcrypt 1.7.0
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Here is another session after another three times failure.

This time, unblock by admin with Admin PIN.

$ gpg --card-edit

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 0 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

gpg/card> admin
Admin commands are allowed

gpg/card> passwd
gpg: OpenPGP card no. D276000124010200FFFE870215340000 detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 2

[ Admin PIN ]
[ New PIN ]
[ Repeat New PIN ]

PIN unblocked and new PIN set.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? q

gpg/card>

Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.1.9-87021534)
00 00
Application ID ...: D276000124010200FFFE870215340000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 87021534
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 6E9A 631F 1997 F37C 7F4E 9952 8916 1D16 AA0D B710

created ....: 2016-05-19 05:09:13

Encryption key....: 0138 70C9 FA89 986F 2784 31A9 8AAA 8F21 ABD4 A70C

created ....: 2016-05-19 05:09:13

Authentication key: B2FE 8DAF 9494 3320 760F 38E2 30F6 A992 6870 02D6

created ....: 2016-05-19 05:11:14

General key info..: pub rsa4096/AA0DB710 2016-05-19 Chuji Kunisada
<chuji@gniibe.org>
sec> rsa4096/AA0DB710 created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/ABD4A70C created: 2016-05-19 expires: never

card-no: FFFE 87021534

ssb> rsa4096/687002D6 created: 2016-05-19 expires: never

                        card-no: FFFE 87021534

$

This is no longer an issue with gnupg master:

% socat - tcp-listen:11371
GET /pks/lookup?op=index&options=mr&search=foobr HTTP/1.0
Host: localhost:11371
Connection: close
Via: 1.0 tinyproxy (tinyproxy/1.8.3)
Pragma: no-cache
Cache-Control: no-cache

Feel free to reopen with more specific information.

I think this can be resolved. Yes older versions did not allow pasting but
recent versions do allow this. So we've fixed the bug in recent versions ->
resolved. No?

The reporter says he is using ubuntu 14 (i assume 14.4) where the default
pinentry is pinentry-gtk2 0.8.3

Thank you for your report and the log, but it doesn't have useful information so
that I can debug.

The information of card reader is required, if the problem happens for specific
card reader only. Please include full log which includes card reader information.

There seems to be a problem with your reader. We would need to closer analyze
the log (which I copy below):

DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
DBG: ccid-driver: PC_to_RDR_IccPowerOn:
DBG: ccid-driver: dwLength ..........: 0
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bPowerSelect ......: 0x01 (5.0 V)
DBG: ccid-driver: [0008] 00 00
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 21
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 3B DA 18 FF 81 B1
DBG: ccid-driver: [0016] FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: PC_to_RDR_SetParameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bProtocolNum ......: 0x01
DBG: ccid-driver: [0008] 00 00 18 10 FF 75 00 FE
DBG: ccid-driver: [0016] 10
DBG: ccid-driver: RDR_to_PC_Parameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: protocol ..........: T=1
DBG: ccid-driver: bmFindexDindex ....: 18
DBG: ccid-driver: bmTCCKST1 .........: 10
DBG: ccid-driver: bGuardTimeT1 ......: FF
DBG: ccid-driver: bmWaitingIntegersT1: 75
DBG: ccid-driver: bClockStop ........: 00
DBG: ccid-driver: bIFSC .............: 254
DBG: ccid-driver: bNadValue .........: 16
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 5
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] 10 C1 01 FE 2E
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 00 82 00 82
DBG: ccid-driver: invalid response for S-block (Change-IFSD)
apdu_send_simple(0) failed: unknown host status error
DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0

Without pcscd running, I get a "Not supported" error. The scd.log is attached.
Using pcscd, it works, except for that special case.

debug 2048
debug 1024

is what I need.

Thanks. We need to know some more detailed information. Please
put

debug 2018
debug 1024
log-file /somewhere/scd.log

into scdaemon.conf, kill scdaemon and try again. It seems you have not yet been
asked for a PIN so the log won't reveal the PIN. Anyway, you may want to send
the log to me by PM (wk@gnupg.org - key 1e42b367).

Fails with 2.0.29 too, compiled from source. With enabled debug-all verbose in
scdaemon.conf, the log ends with:

2016-03-19 10:12:09 scdaemon[1988] DBG: response: sw=6A88 datalen=0
2016-03-19 10:12:09 scdaemon[1988] operation decipher result: Missing item in object
2016-03-19 10:12:09 scdaemon[1988] app_decipher failed: Missing item in object
scdaemon[1988]: chan_7 -> ERR 100663364 Missing item in object <SCD>
scdaemon[1988]: chan_7 <- RESTART
scdaemon[1988]: chan_7 -> OK

Yes you are using pinentry, and we need to know what kind of pinentry (there are
several flavors) and which version you are using in order to help you.

Please do 'pinentry --version' and report the output.

To see whether this pinentry is the one you are using, or to play around with it
and the variants, you can do:

echo -e "SETDESC Does this look like your pinentry window?\nGETPIN" | pinentry

You can try replacing pinentry with pinentry-qt for example.

Since the last activity on this report, GpgOL was changed a lot.
Probably the original reporter does not use the Windows/Outlook combination
anymore. Thus closing this report.

On Friday 26 February 2016 at 11:45:07, xyzspeedy via BTS wrote:

We think, there ist a Problem in the Oulook-(Plugin)-Config on the tested
Systems, but i'm not sure,

Hi,

If Gpg4win was already installed a new install with inst_gpgol=false will not
uninstall it. For this you have to uninstall first.
(With the upcoming gpg4win-3.0.0 we are changing that and are always calling
uninstall first on update.)

You can disable an installed GpgOL by setting the registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\GNU.GpgOL]
"LoadBehavior"=dword:00000000

As this can be overridden on a user level you might also want to check the same
key in HKEY_CURRENT_USER context.

With regards to the crashes. I'm sorry to hear that. We had an extremely nasty
bug that could cause random crashes unrelated to crypto operations ( T1837 )
that bug was only fixed with gpg4win-2.3.0.

Regards,
Andre

Hello Andre,

i think, we can close this Ticket, You're Right.

But:
We have tested on more than five Systems with the attached INI and with

[gpg4win]
inst_gpgol = false

Call: gpg4win.exe /S /C={path}\gpg4win.ini (local or Network)

But gpgOL was installed an all Systems.

Then - after reading your Post - we tested on fresh Systems with Outlook 2013:
In all INI-Variations with 'inst_gpgOL=false', gpgOL was NOT installed.

We think, there ist a Problem in the Oulook-(Plugin)-Config on the tested
Systems, but i'm not shure, what we can do but not creating new Profiles.
I don't know, why the gpgol.dll ist installed on the mismatched
Outlook-Configurations. On fresh Systems 'inst_gpgol=false' works.
December 2015 up to January 2016, Outlook 2010 and 2013 running very
instable (crash one to five times per day) - with or without pgp.

When we have an answer from our Side, we tell you.

Greetings,
Joachim

see attached, this is a part of gpg, enter password, I need to be able
to paste into that field. Nobody seems to know how to fix this!

I'm not using pinetry, it is part of the pgp software. just trying to
get to the bottom of this. I am a user, not a programmer. Pinetry just
makes the popup that's asking for the password. I attached a screenshot
of it.

Note: recent versions of pinentry-gtk-2 are using native widgets. If you are
using that program and not the latest version of pinentry, then please try that
first.

MDK7MX, did you retry ?

Ping.
Please tell us the OS version and the GnuPG version.

Please ask on the gnupg-users mailing list for help. This is a bug tracker and
not a help forum, sorry.

Duplicate of T1837

Closing this as noinfo.

Probably the same problem as handled in T1837

Okay, Feel free to re-open if you see it again.

Hi Neal, I am not able to reproduce the issue with GnuPG 2.1.10 anymore.

UPDATE: The latest gpg on an AIX box that I could get my hands on does not work
at all, so until that problem is resolved I cannot really test further.

When we invoke gpgme a process just hangs, but as far as we can tell from the
strace, gpg is busy closing file descriptors in the entire file descriptor
range! If we limit the file descriptor range to a smaller number (by, say,
"limit descriptors 4096 ; limit -h descriptors 4096"), we get a fast failure.

The gpg versions we have installed are 2.0.26 and 1.4.18. It seems that the
pinentry program never even gets invoked. Attached is a program you can test with.

Given that this bug does not appear to be reproducable with 0.9.6, I'm marking
this as resolved.

Given how long it has been since this bug was reported, the request for more
information and the lack of response, I'm going to mark this issue as resolved.

It would nice to have an exactly sequence of commands that cause this problem.

Chris, please take this to one of the mailing lists (gnupg-usewrs@gnupg.org).
You want a discussion about this and thus the bug tracker is not the right media
for you. Please do not re-open this bug again.

We provide all kind of means to verify the software and the default is now to
use the also-easy-to-subvert https for those who are not able to verify
signatures or checksums.

Also feel free to provide a verified copy of the software from your own boxes
and announce that to the Gpg4win lists.

Mate - it's this simple. For as long as you're distributing a security
product over plaintext insecure channels, this bug needs to stay open.

TLS will NOT prevent anyone downloading this, no matter how hard you cling
to that irrational idea. If you work for someone who is exploiting this
attack vector SHAME ON YOU!!!

Stop wasting everyones time. If you don't want to fix this, go away and do
something else, stop preventing someone who *can* fix it from actually doing
that by messing with this ticket.

This bug report is very old and 2.0.17 is no longer supported. The right way
forward is to rerun the test suite with the latest version on a modern OS.
However, I expect that if these failures were still a problem, we'd have heard
about them. As such, I'm closing this bug.

I am pretty sure that there is a race. The two sessions are not mutally locked
and thus the second client may ask for the passprase again.

  Pinentry-1 returns to Client-1
  task switch
  Client-2 now checks the cache again, does not see an update, starts Pinentry-2
  task switch
  Client-1 updates the cache

How ever it will be a rare problem and it would at best be annoying.

I tried running:

  echo | gpg -s -a

in two terminal. In the first terminal, I got a pinentry prompt (I'm using
pinentry-tty) and in the second, gpg2 appeared to freeze. Once I entered my
passphrase correctly in the first terminal, the first gpg2 process split out the
signed message and less than a second later, the second did as well.

The code also suggests that this is fixed (agent/findkey.c)

      /* If the pinentry is currently in use, we wait up to 60 seconds
         for it to close and check the cache again.  This solves a common
         situation where several requests for unprotecting a key have
         been made but the user is still entering the passphrase for
         the first request.  Because all requests to agent_askpin are
         serialized they would then pop up one after the other to
         request the passphrase - despite that the user has already
         entered it and is then available in the cache.  This
         implementation is not race free but in the worst case the
         user has to enter the passphrase only once more. */

Interestingly, this comment is from 2006 (commit: df52700f), which predates this
bug report.

As such, I'm changing this bug's status to needs-eg. Perhaps Werner can shed
some more light on this issue.

I don't think it makes sense to wait longer for a response.

What we can take with from this report and similar in the past is that the
asprintf emulation (von gnulib) is troublesome. We should eventually replace
them by the libgpg-error printf functions. It is a dependency anyway. We only
need to bump up the required version.

ciil: Thanks for the update!

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

Sorry, this question was lost due to Christmas, or whatever...

I can't reproduce this problem.

GpgOL tries to talk to Kleopatra through a file in %APPDATA%\gnupg

please make sure the permissions on this folder are correct. If you started
things with Administrator privileges before there might be files in there that
are only accessible for administrators and not with normal user rights.

Which libassuan version are you using?
libassuan-config --version
should show it.