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

Thanks. I took your solution.

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

gpgme 1.7 will have gpgme_op_createkey which takes "default" and
"future-default" as algorithm parameters. There is also a bunch of user
functions to make creating a key easy with gpgme.

This has been implemented in the repo to be released with 2.1.16.

This has meanwhile been done.

No bug, Use "cert" and not "certify".

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.

@werner, if you prefer ntbtls over gnutls, okay. Can you add a link to ntblts
and outline the next steps. We'd probably need tls support for the web key
directory as well, so this needs a solution.

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.

It is a hack in OpenKeychain to allow the use of several devices. Frankly, I am
not sure whether this is really a good idea: The security is limited by the key
for the least secure device.

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?

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.

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

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.

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

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?

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.

Are the ownertrust values identical on boths systems?

Compare the output of

gpg --export-ownertrust | sort

on noth systems.

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.

Can you please test with 2.1.15?