The file has been completely rewritten for 1.6 and thus there is nothing to fix
for the current version. Thanks anyway for this report.

Sorry for the long delay. Fixed with commit 8c5eee5 for 1.7.

I won't backport it to 1.6 because the leak is only triggered by wrong usage of
the functions.

Note that gpg-agent is responsible for this. The agent calibrates the s2k count
so that the KDF takes about 100ms. Actually this is the default since 2.0
something (at least a couple of years). Note that the s2k count is still used
for symmetric encryption.

It is an open question whether gpg should be allowed to change the s2k options
because the keys are a property of the agent and not of gpg. For export it
might hwoever make sense to be able to change that (think export for use on a
slower box).

Sorry, this is not a bug. If you configure with out TLS support it simply can't
do that. In case you are talking about the Windows installer, please note that
this binary version is marked as experimental with several limitations

The ticker is responsible for several house holding tasks and thus we can't
simply disable it or set it too a much higher value. Currently this might be
some easy things but at least the check whether the socket has been taken over
by a second instance (what you call "permission check") is important and can't
be delayed for too long. Given that dirmngr and more import scdaemon also have
such ticker jobs, I doubt that this would lead to any noticable power saving.

Note that some years ago the code was modified to make sure that gpg-agent wakes
up at the full second so that it matches the tickers of other processes.

werner: Please go ahead.
I don't have enough knowledge about keybox implementation (and its plan).
My message is basically to share information, and my proposed change is not the
real fix, but something
pointing the (major) cause.

Any objections to upping the value?

It looks like it's due to TIMERTICK_INTERVAL being set to 2 on UNIX platforms so
that it can call handle_tick() every 2 seconds. It looks like handle_tick() just
checks if we've lost our connection to scd, if we've lost our parent, and less
frequently that the socket permissions are correct.

I'm not sure why we would need to check these things every two seconds. Also we
could detect parent death (on linux at least) via PR_SET_PDEATHSIG instead of
polling.

Done.

i've tested this with gnupg 2.1.1, and gnupg 2.1.1 does provide a non-zero
return code if the passphrase fails.

This won't be fixed for 2.0 but I will consider to do something about it in one
of the next 2.1 releases.

No, you do not need a second bug for --delete-secret-key.

gniibe: If you want to fix that, please assign the bug to you, otherwise I
assign it to me in a few days.

(removing the PPG-2 support wasn't the easy job expected)

I guess that is possible. gpgsm does not get much attention these days.

May be close this bug?

I changed this to a gpa bug. gpg4win does not yet use GnuPG 2.1

Yes, that is very likely. Check the list for a workaround.

Duplicate of T1793

The latest version is 0.9.7. Please report error only against the latest version.
It has likely been fixed.

edit: This is probably a duplicate of 1793

Could this case please get some attention. This is still an issue for me and
everyone else I know using GPA for windows. Can I help with any more information?

Thank you for the feedback.

You're right, I don't kwnow why I didn't see it. I was blocked on the default value.

Thank you for your report.

I think the document is right. Yes, it's somehow confusing.

It explain "two conditions" using GPG default values, but then,
it says : "This example assumes that two marginally-trusted keys
or one fully-trusted key is needed to validate another key.
The maximum path length is three."

It would be better explaining with default values, though.

In 2.1, secret key handling has been changed.
It's now *not* in secring.gpg but files under private-keys-v1.d.
I think that there were some migration problems for your environment (and GnuPG
2.1.0) and one of your secret key is not converted.

I don't know the reason, but I guess that your key is only available in
secring.gpg and not in pubring.gpg.

About secret key reference (in secring.gpg for 1.4/2.0, under private-keys-v1.d
for 2.1) can be generated by accessing card.
With 2.1.1, --card-status will register key reference. With 2.1.0, you can do:

  $ gpg-connect-agent learn /bye

Once you have public key entry and private key reference to your card, it should
work well.
Could you please try installing your public key with 2.1.0 and making private
key reference?

I confirmed that --check-trustdb results broken trustdb.
We can check by --list-trustdb.

It should be something like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=0, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=6, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=6, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=6, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=6, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

But 2.1.1 updates like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=1, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=2, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=2, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=2, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=2, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

That is, DEPTH=1 and VALIDITY=2, which is wrong.

I investigated and realized that keybox_search function in kbx/keybox-search.c
is not yet mature. That is, it doesn't support skipfnc yet.

In this situation, something like following is needed:
diff --git a/g10/trustdb.c b/g10/trustdb.c
index 1bf664b..a946c29 100644

• a/g10/trustdb.c

+++ b/g10/trustdb.c
@@ -1625,6 +1625,12 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust,

merge_keys_and_selfsig (keyblock);
clear_kbnode_flags (keyblock);
pk = keyblock->pkt->pkt.public_key;

+ if (search_skipfnc (full_trust, pk->keyid, NULL))
+ {
+ release_kbnode(keyblock);
+ continue;
+ }
+

if (pk->has_expired || pk->flags.revoked)
  {
    /* it does not make sense to look further at those keys */

Yes, please send by private mail. You might already know my key:

pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]

Key fingerprint = 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367

uid [ full ] Werner Koch <wk@gnupg.org>

Reducing priority from critical to urgent since there is now a workaround known:

• move .gnupg to .gnupg.old
• gpg --import .gnupg.old/pubring.gpg
• gpg --import .gnupg.old/secring.gpg
• cp .gnupg.old/trustdb.gpg .gnupg

Also using a version with 94a5442 reverted and importing a new key seems to fix
this issue for me also when 94a5442 is applied again afterwards.

I can send you both versions of the keyring, a defect and a working one.

For comparison, running the below commands using gpg 1.4.18, does *not* exhibit
the bug - after importing dkg's key, my own key's validity remains as "ultimate".

I can send my keyring to you but I would not like to make it public. Is a private
mail with a download link ok?

Just noticed: It is a keyring. So first question already answered.

I would be helpful if you could provide an example keyring and a list of keys
which have a secret key. As an alternative I like to know:

• Are you using the keybox or the keyring format (commonly ".kbx" or ".gpg").
• Is the version 3 key the first, inbetween, or the last key in the key storage?

Well, that is quite possible. I have seen other reports about this. I have not
yet come around to look at the hkps bugs.

Not a problem with 1.6.2
thank you

Windows does not allow file names with a '*'. I'm not sure on what level but Its
ok not to handle this case.
I don't expect any problems for internal usage. Keep in mind that this is a
regression, we had wildcard expansion before we made the switch to mingw-w64.

We also don't need this in gpgwrap as gpgwrap just passes the argument on and it
will be expanded in the process itself.

But I actually like the idea to do the wildcard expansion in kleowrap / gpgwrap.
This way it would be contained in Gpg4win and we catch all our "user exposed"
processes. Ok?

I won't do that just for gpg - this would be inconsistent. The wrapper we put
into the PATH directory needs this as well. What about gtk and qt libraries -
they run exe files internally - will the quoting continue to work? A single '*'
in a file name would likely break Enigmail.

Several such bugs have been fixed in the meantime. I can't repeat it anymore.

Well just gpg would be enough imho as this is by far the most prominent command
line tool.

On the other hand it might be more prudent for us to hack / patch it just in the
gpg4win build to have it enabled globally for all tools we ship so that it is
more consistent. This would mean patching the compiler tough which we tried to
avoid so far.

I would be fine with moving this patch to the version independet gnupg2 patches
in gpg4win as it is kind of a "distribution" option forced upon gpg4win by the
compiler we are currently using.

Werner: If you agree please give a short ping here and I'll move the patch /
close the issue.

original; report was for the dirmngr package. Won't fix it there.