This is an issue of GNOME as packaged by Red Hat. Please file a bug in Red
Hat's bug tracker instead.

I'm on T2448 (aheinecke on Sep 05 2016, 02:14 PM / Roundup).

Jochen, is T2448 (aheinecke on Sep 05 2016, 02:14 PM / Roundup) something you could do?

I don't have sufficient permission to upgrade gnome session, so if you have
any idea suggest me

@werner, if I understand the description at
https://www.gnu.org/software/tar/manual/html_section/tar_68.html
then ustar would also be able to read "posix" archives.

Thanks. I took your solution.

ustar is the format introduced by PGP 6; also for Windows. This is the only
reason we use it. PGP users demanded that we support that "pgpzip". We can't
drop it.

Use a recent gnome version and you are fine.

Sorry, I cannot reproduce this problem using 2.1.11:

% export GNUPGHOME=$(mktemp -d)
% echo "keyserver hkps://hkps.pool.sks-keyservers.net
hkp-cacert
/home/teythoon/repos/g10/gnupg-2.1.11/dirmng/sks-keyservers.netCA.pem" >
$GNUPGHOME/dirmngr.conf
% g10/gpg2 --recv-keys 99B03CE455DB476E737057B44FD0FA5528DB9E3F
gpg: /tmp/tmp.QINMXRcRqH/trustdb.gpg: trustdb created
gpg: key 28DB9E3F: public key "Justus Winter <justus@gnupg.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
% g10/gpg2 --refresh-keys
gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
gpg: key 28DB9E3F: "Justus Winter <justus@gnupg.org>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

(Adding the .onion service makes no difference for me either.)

What I meant by "KArchive" is that we already have all that nice archiving code
in Kleopatra already: https://api.kde.org/frameworks/karchive/html/index.html
To work with standard formats like tar / zip / 7zip etc.

This would get us the included platform abstraction through Qt for stuff like
filenames etc. and we wouldn't have to maintain our own implementations for
these archive formats.

Can you create a new issue with the data "loss" part?

As for the default format:
I think we should use and propose a default format that is mostly compatible
over platforms (and robust in the future). tar "posix" seems to be
such a format. Am not sure how this evaluates for karchive or 7zip.

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?)