https://www.gnu.org/software/tar/manual/html_section/tar_68.html gives a good
overview imo.

So yes raising the file name length limit could be problematic with
compatibility and we might have to change more in our implementation to create
formats of a different spec.

From the discussion in the forum it looks like the error was silently discarded
when used in Kleopatra. We need error handling in that case. So I think this is
an Urgent bug as silent discard of archive contents can lead to data loss. So
for me this part is an urgent bug. Actually handling longer filenames is another
issue.

As a sidenote:
Kleopatra already links KArchive for svgz handling so it already contains a good
API for ZIP file creation. I'd like to add that to Kleopatra and make it default
so that the default is not our own error prone tar implementation. (Other tar
implementations also are problematic for windows). In that case we could also
drop the extraction as zip file support is native in the windows file explorer.

And as suggested in the forum entry we should probably also document how to add
7zip support to kleopatra or check for this at runtime and add some 7zip archive
options if it is available.
This should be doable by editing libkleopatrarc but I'd have to check the syntax
myself in the code as its not documented afaik.

..it was an error from kwallet. So I had gpg new installed from source. By
installing I have seen, that kwallet make problems, so I install also kwallet
completely new.
Now there is no error-message from gpg. I'm happy. Sorry to all, but I didn't
know, what to do before.

Indeed, this is unfortunate, but not as bad as you make it sound (unless the
user uses always trust).

Note that this is not about signing (which uses the private key), but about
encryption. I've changed the bug title accordingly.

This happens also with master, and it seems the order of keys in the public
keyring is important:

teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.TR2cSoWHMb/pubring.kbx' created
gpg: /tmp/tmp.TR2cSoWHMb/trustdb.gpg: trustdb created
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: 1A7265CF27F9E78E: There is no assurance this key belongs to the named user
sub rsa2048/1A7265CF27F9E78E 2016-09-14 test.user@example.org
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Primary key fingerprint: CA77 8656 2AAC BBB2 6A50 3A50 8D62 594F 1FE9 0C7B

      Subkey fingerprint: 52CB E9DC 1812 9F78 3054  6569 1A72 65CF 27F9 E78E

It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting
130 teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export
GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.Hfjbb2jvji/pubring.kbx' created
gpg: /tmp/tmp.Hfjbb2jvji/trustdb.gpg: trustdb created
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: DAB278A8736B0D2C: There is no assurance this key belongs to the named user
sub rsa2048/DAB278A8736B0D2C 2016-09-14 user@example.org
Primary key fingerprint: 6680 B181 D853 CEB5 6671 ECC7 0098 8FEC 00B5 CA77

      Subkey fingerprint: 3909 7C31 399C A746 87B3  5D74 DAB2 78A8 736B 0D2C

It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting

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

Any suggestion on how to detect utf-16 easily?

Any suggestion on how to detect utf-16 easily?

What you see is no output but diagnostic messages send to stderr.

Spoke to Werner, it is better to do ntbtls anyway.
Timeline is: this year, hopefully earlier.

For ntbtls also see: https://wiki.gnupg.org/NTBTLS

ntbtls is a development from Werner:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=ntbtls.git;a=summary

What about using https://tls.mbed.org/? At least until ntbtls is mature?

Good catch. I fixed usbmod in the repo.

Please ask on gnupg-users or any other public resource for help. This is a bug
tracker and not a help line.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1362477

I tested with 2.0.22 on Ubuntu 14.04.5 LTS and SIGHUP expired the cached
passphrase. I'll have to find some time to test 2.0.30.

So i see a couple options:

a) We import a secret key -- this requires that we launch the agent to store it.
b) We import a public key and see that its preferences do match our
implementation -- in this case, we don't need to talk to the agent, right?
c) We import a public key and see that its preferences do not match our
implementation -- in this case, we could check whether the agent has the
corresponding secret key, and if it does, we could complain to the user.

instead of (c), though, we could trigger such a test the other way around: if
we're using a secret key and we notice that its public preferences don't match
our implementation, that's when we could warn the user about the mismatch.

What both won't give you is the key actually used as default key. A
test signing might be a better way to figure out the default key:

  $ fortune | gpg -sv -o /dev/null --status-fd 1
  gpg: using "1E42B367" as default secret key for signing
  gpg: using subkey 4F0540D577F95F95 instead of primary key F2AD85AC1E42B367
  [GNUPG:] KEY_CONSIDERED 80615870F5BAD690333686D0F2AD85AC1E42B367 0
  gpg: writing to '/dev/null'
  [GNUPG:] BEGIN_SIGNING H2
  [GNUPG:] PINENTRY_LAUNCHED 960
  gpg: DSA/SHA1 signature from: "4F0540D577F95F95 Werner Koch <wk@gnupg.org>"
  [GNUPG:] SIG_CREATED S 17 2 00 1473143881 E4B868C8F90C8964B5AF9DBC4F0540D577F95F95

The used key can be taken from the SIG_CREATED status line. This is
not the primary key, so we may want to add anoter status line. To
avoid the Pinentry this could be used:

  $ fortune | gpg -sv -o /dev/null --status-fd 1 --pinentry-mode=cancel
  gpg: using "1E42B367" as default secret key for signing
  gpg: using subkey 4F0540D577F95F95 instead of primary key F2AD85AC1E42B367
  [GNUPG:] KEY_CONSIDERED 80615870F5BAD690333686D0F2AD85AC1E42B367 0
  gpg: writing to '/dev/null'
  [GNUPG:] BEGIN_SIGNING H2
  gpg: signing failed: Operation cancelled
  [GNUPG:] FAILURE sign 67108963

along with a new status line.

Thanks. It happens only for a new or modified key. The reason is that we then
check that the preferences of the key match our implementation. This check
makes only sense if we have the secret key and to detect this we need to start
the agent.

To avoid this, we would need to implement yet another gpg option.

Or we use a hack to detect the presence of the private-keys-v1.d directory.
That would solve the problem for now but not if the agent is accessed via the
--extra-socket feature.

So i've tested this locally with:

    export GNUPGHOME=$(mktemp -d)
    gpg --quick-gen-key 'test user <test@example.org>'
    gpg --armor --export-secret-key 'test user <test@example.org>'

(choosing no passphrase during the prompts that come up during the quick-gen-key
step). The final export step works fine.

Can you show what steps you're taking that fail for you, Andre?

sure: using the attached "dkg.gpg" file (a pruned version of my own public key),
i did:

if --list-config is deprecated, should it emit a warning? doc/gpg.texi shows no
mention that it is deprecated, or that "gpgconf --list-options gpg" should be
preferred.

Also, i note that --list-config is still used in the test suite:

tests/openpgp/defs.inc uses it with "ciphername" and "digestname", and
tests/openpgp/defs.scm uses it with "ciphername" and "digestname" and
"pubkeyname". I don't see any way to get the same information out of gpgconf.
Perhaps gpgconf needs to provide some equivalent?

No, it's not the config files that are a problem. And maybe I'm using
imprecise terminology. But, the gpg-agent process maintains an open
handle on the current working directory in which the process is started,
until it is killed. Here's an example:

Thanks for clarifying this.

I've update the comment in the test accordingly. This issue is resolved for me.

--list-config is an old interface which has been superseeded by gpgconf.

OpenPGP has a timestamp granularity of one second and thus you can't distinguish
non-RSA signature from each other if they are donewithin the same second.

Waiting a second is an old trick which is even employed somewhere inside gpg.

The leading and trailing garbage is by design - cf. >20 years discussions on the
problem of the cleartext format. A --verify works best with a detached
signature, because only this format makes it easy to decide what has been signed.

We need to review why --output has no effect with --verify or gpgv.

There is no lock on a directory. However, several lock files are created in the
GNUPGHOME directory. Sure, you can't delete them as long as the processes
holding them are alive.

Can you please give more detailed information on your problem? For example the
name of the lock files and which processes are holding them? How can we
replicate the problem.

Can you please given an ezample - I can't replicate it.

I'm using latest master and I still can't export a secret key without passphrase.

And Justus also has not closed this bug or wrote that he commited something
more. So I think the 2.1.13 announcement was mistaken and this problem still
exists. (Or am I missing some option / need a different pinentry mode?)

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.