Jochen: I'd rather you (manually) patch the dirmngr tarball included in
gpg4win-2 and create a testinstaller and try that one out.

I found the Problem in this issue and tested that the attached patch solves the
problem, yes It would have worked on GNU/Linux as the "b" has no effect there.
Finding out since when the problem existed appears moot to me and you would have
to check in dirmngr's SVN and likely always existed.

But maybe there are additional problems (as this is imo a very exotic feature)
so it would probably make sense to test it again on Windows before preparing the
next stable Gpg4win release.

Thanks, this works now as expected.

While enabling the checks for signcount in gpgme/lang/qt/tests/t-tofuinfo.cpp
I've noticed though that if I sign and verify the same plaintext twice
immediately after another the signcount is not incremented correctly.

In line 266 of that test. The call to signAndVerify leads to an Assert if you
remove the " World" part of the "Hello World" message.

Alternatively adding a QTest::qWait(1000); before that line also results in a
success.

You can trigger this also by modifing the strings in line 233ff to contain the
same message.

Not really important imo as this is a constructed problem. The main issue here
is resolved for me.

Jochen, can you please find out:
a) Does this still work on GNU/Linux?
b) Did this work with elder Gpg4win version? With binary search you

should find out qickley when this broke.

When initially started from the command line (either directly or secondarily via
gpg --sign ..., the gpg-agent creates a lock on the current directory and
doesn't release it until gpg-agent exits.

This makes the directory un-deleteable until the process is killed. If it needs
a lock, it should lock an essentially unremovable directory (such as
%USERPROFILE%, if it needs to be user-owned).

This is a especially a problem when signing files which are in a temporary
directory (such as packages prepped for distribution) which would then be
deleted (with the enclosing directory).

I've noticed this is a problem ever since the 2.0 release using a graphical user
agent.

Thanks for taking the time to look into the problem.

I observed the same behavior with --import.

Updated by the fix:

f9e49c8 scd: Fix an action after card removal.

Fixed in master.

f9e49c8 scd: Fix an action after card removal.

I confirmed that it's a regression in 2.1.15.

Fixed in master:

    8fe8105 scd: Release the card reader after card removal.

In my environment, it works both for PC/SC and in-stock CCID driver.

Not yet for 2.0 and 1.4.

No they are differents.

I have 89 values on Linux and 81 values on Windows.

diff win-owner.txt rhel-owner.txt
12a13

47FB20102BAEB52CB6DC56177129CB6A081FEBAD:5:

20a22

5855DD9E25B9A8DC2FBA57AA6F7844ED8F847C04:5:

31a34

7973C95FEF2CB9DB2BFE28344A0A560FB0B37102:5:

45a49

9A21AEC12074E70350F6A7E34A7395B4E1F81D9F:5:

52a57

AAB5C4863EEC5C7F19CF2BA4203A3B252B338A13:5:

71a77

E3B8C9513CDE7EE4525E2D2DC8A0CB9453732618:5:

75a82

F47ABE16FE74A02D8D91F742AF1E698C4C389893:5:

77a85

F9769C31CD79BA5B71385546C66AA2A8FF3DC51E:5:

In the above diff, I noticed the value AAB5C4863EEC5C7F19CF2BA4203A3B252B338A13
which correspond to TEST.MASTER

I think there is no such keyword in GnuPG
2.1.x source code. _pgpkey-http only can be
found in GnuPG 1.4.

hm, there is also:

    gpgconf --list-options gpg | \
         awk -F: '/^default-key:/{ print $10 }'

It's not clear to me when anyone should use "gpgconf --list-options gpg" and
when they should use "gpg --with-colons --list-config".

Is there some place where one or the other is more important?

How about _pgpkey-http._tcp. record?

I believe that this bug has been fixed. Both Andre's and Justus' test cases now
emit the same information for all user ids (see below).

If you agree that this issue is resolved, please change the status appropriately.

us@grit:~/neal/work/gpg/build/gpgme/tests/gpg$ rm -f $GNUPGHOME/tofu.db && ( gpg
--verify --with-colons --status-fd=1 /tmp/testmsg )2>/dev/null
[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED A0FF4590BB6122EDEF6E3C542D727CC768697734 0
[GNUPG:] SIG_ID QfzOUKyR2prNsVx/GI/4A5q2AxU 2002-03-03 1015172412
[GNUPG:] KEY_CONSIDERED A0FF4590BB6122EDEF6E3C542D727CC768697734 0
[GNUPG:] GOODSIG 2D727CC768697734 Alfa Test (demo key) <alfa@example.net>
[GNUPG:] VALIDSIG A0FF4590BB6122EDEF6E3C542D727CC768697734 2002-03-03 1015172412
0 4 0 17 2 00 A0FF4590BB6122EDEF6E3C542D727CC768697734
[GNUPG:] KEY_CONSIDERED A0FF4590BB6122EDEF6E3C542D727CC768697734 0
[GNUPG:] TOFU_USER A0FF4590BB6122EDEF6E3C542D727CC768697734 alfa@example.net
[GNUPG:] TOFU_STATS 2 1 0 auto 1472727595 1472727595
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alfa Test (demo key)
<alfa@example.net>"%0Ain the past 0~seconds.
[GNUPG:] TOFU_USER A0FF4590BB6122EDEF6E3C542D727CC768697734 alpha@example.net
[GNUPG:] TOFU_STATS 2 1 0 auto 1472727595 1472727595
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key)
<alpha@example.net>"%0Ain the past 0~seconds.
[GNUPG:] TOFU_USER A0FF4590BB6122EDEF6E3C542D727CC768697734 alice%20(demo%20key)
[GNUPG:] TOFU_STATS 2 1 0 auto 1472727595 1472727595
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain
the past 0~seconds.
[GNUPG:] TRUST_MARGINAL 0 tofu

us@grit:~/neal/work/gpg/build/gpgme/tests/gpg$ ../../../gpgme/tests/run-verify
/tmp/testmsg
Original file name: [none]
Signature 0

status ....: Success
summary ...:
fingerprint: A0FF4590BB6122EDEF6E3C542D727CC768697734
created ...: 1015172412
expires ...: 0
validity ..: marginal
val.reason : Success
pubkey algo: 17 (DSA)
digest algo: 2 (SHA1)
pka address: [none]
pka trust .: n/a
other flags:
primary fpr: A0FF4590BB6122EDEF6E3C542D727CC768697734
tofu addr .: alfa@example.net
  validity : 2 (little history)
  policy ..: 1 (auto)
  sigcount : 1
  firstseen: 1970-01-01 00:01:46
  lastseen : 1970-01-01 00:01:46
  desc ....: Verified 1 message signed by "Alfa Test (demo key)

<alfa@example.net>"

             in the past 1 minute, 46 seconds.
tofu addr .: alpha@example.net
  validity : 2 (little history)
  policy ..: 1 (auto)
  sigcount : 1
  firstseen: 1970-01-01 00:01:46
  lastseen : 1970-01-01 00:01:46
  desc ....: Verified 1 message signed by "Alpha Test (demo key)

<alpha@example.net>"

             in the past 1 minute, 46 seconds.
tofu addr .: [none]
  validity : 2 (little history)
  policy ..: 1 (auto)
  sigcount : 1
  firstseen: 1970-01-01 00:01:46
  lastseen : 1970-01-01 00:01:46
  desc ....: Verified 1 message signed by "Alice (demo key)"
             in the past 1 minute, 46 seconds.

For version 2.1.15

root@47b54eb8e5bb:~/gnupg-2.1.15# gpg2 --version
gpg (GnuPG) 2.1.15
libgcrypt 1.7.3-beta
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://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: /root/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
root@47b54eb8e5bb:~/gnupg-2.1.15# gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye
OK - System resolver w/o Tor support
root@47b54eb8e5bb:~/gnupg-2.1.15# gpg2 --keyserver hkp://t1.zhsj.me --recv-keys 7DFBB2F2
gpg: keyserver receive failed: End of file
root@47b54eb8e5bb:~/gnupg-2.1.15# gpg2 --keyserver hkp://t2.zhsj.me --recv-keys 7DFBB2F2
gpg: keyserver receive failed: No keyserver available

For version 2.1.11
zsj@debian ~ $ gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.7.3-beta
Copyright (C) 2016 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, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
zsj@debian ~ $ gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye
OK - System resolver w/o Tor support
zsj@debian ~ $ gpg2 --keyserver hkp://t1.zhsj.me --recv-keys 7DFBB2F2
gpg: key 7DFBB2F2: "Shengjing Zhu <i@zhsj.me>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
zsj@debian ~ $ gpg2 --keyserver hkp://t2.zhsj.me --recv-keys 7DFBB2F2
gpg: keyserver receive failed: No keyserver available
zsj@debian ~ $

Please run

gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye

Are the ownertrust values identical on boths systems?

Compare the output of

gpg --export-ownertrust | sort

on noth systems.

curses can't figure out the window size and thus it returns -1 for the size.
Pinentry's test for the required window size thus returns an error.

I have added new error codes to libgpg-error to either return
ERR 83886383 Screen or window too small <Pinentry>
or in our case:
ERR 83886383 Required environment variable not set <Pinentry>

That does not directly point to a problem with the TTY but it shows the cause
for the error (COLUMNS, LINES etc not set).

Since the split format has been removed, the relevant code is gone, and I'm not
able to reproduce the issue with your test case on HEAD, I think this issue is
also gone and I'm marking it resolved. Please reopen if necessary.

this also affects version 2.1.15 (latest gpg4win beta) and 1.1.1 (latest gpg4win
stable)

Okay, if this transfers line endings because of the textmode read, it will
depend on the contents of the CRL in question. This explains why the defect was
not seen in earlier testing.

And pem does not work for this (I guess and tried on a GNU system).
It is okay that pem does not work, because this is a rarely used function I think.

D381: 870_0001-dirmngr-Open-CRL-s-in-binary-mode.patch

Woops didn't want to submit the last message as I had already looked into it myself.

This was reproducible using libksba's t-crl-parse with our root ca's clr but not
with an example file lying next to it.

Turned out that t-crl-parse opened the file in text mode. Conversion errors then
caused an invalid (too large read). When switching to binary mode it worked as
expected.

Dirmngr used the same. I've tested that crl parsing worked with the attached patch.

Now I get:
dirmngr[780]: error fetching certificate by subject: Configuration error
dirmngr[780]: crl_parse_insert failed: Missing certificate

But I think that is a different error as I get the same one when trying to
import the CRL on an empty homedir and parsing works now.

2.1.11 is not in the latest beta. Should be 2.1.13.

For testing / reporting it is also better to download the latest version from
gnupg.org
https://gnupg.org/download/index.html

Right. Putting armor into gpg.conf is a very bad idea. Don't assume that. If
users want to shoot into their own foot, let them do so.

I have seen that but pretty pelase describe it here so that we can also work
with email.

Detail info in https://trac.macports.org/ticket/51708
OS: PPC Tiger, Mac OS X 10.4.11
The build process is automated by macport.

I see. So, how can I reliably know whether the output of my program is going to
be ascii or binary (to append either .asc or .gpg)? I should just assume that
'armor' will not be in gpg.conf?

Can you please test with 2.1.15?

If a user forces all output of gpg to be armored, it is not gpgme's task to
revert this.

Putting armor into gpg.conf is as bad an idea as putting encrypt into gpg.conf.

gpgme_get_armor() returns gpgme's current state.

Please describe exactly how you build Libassuan. Compiler, OS etc, error message.

You are right. Fixed with commit 68fba3d.

--use-agent is a dummy option in GnUPG 2.1 - it has no effect.

1.4 has been released - waiting for 2.0

I used your workaround and haven't been running into problems since. Unfortunately, I
don't currently have the time at hand to give it a thorough test run. If I do, I will
keep you updated.

gpg2 --use-agent --decrypt encrypted.asc
...
gpg: decryption failed: No secret key
FAIL

--use-agent --decrypt encrypted.asc
..
You need a passphrase to unlock the secret key for
...SUCCESS

This for example makes enigmail fail, and to make things worse: enigmail refuses
to work with gpg1

Using:
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
on Ubuntu 16.04.1 LTS

I have multiple keys in .gnupg, this might be triggering the problem.

Indeed; this look like a corrupted file. Please restrore from abckup.

ping

Could you verify that the problem has been solved (in 2.1.14)?