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.

dirmngr is now part of gnupg proper.
Original report was for dirmngr-1.1.0.

Thanks, Fix will go into 1.7.

Is this still a problem with 1.6.2 ?

Is this still a problem with 1.17 - guess yes. Can you please try and send me
the config.log from 1.17 or current master?

The context menu of the key manager now has a "refresh key" item.

Now, shall I add this to gnupg 2.1? To which tools? All or just gpg?

Does the patch work for you?

1.6.2 with the fix was released in August

Released with 1.6.2. on August 21.

2.1.1 has been released.

The sem_post in enter_pth can't set ERRNO because we assert the return value
later. However, the sem_wait in leave_npth has the usual EINTR protection and
thus changes ERRNO. Needs to be fixed.

Okay, fixed with commit 5cb6df8.

No this was on "the master of the day"

And with the dead server detection the case for "localhost lookup" already got
better.

But you could look at npth src/npth.c
I am pretty sure that npth_enter and npth_leave modify errno and that this
causes at least npth_connect not to set errno as expected.

This was straight 2.1.0, right? Please try again with 2.1.1 there are just to
many bugs fixs that it is not worth to look at 2.1.0. If it is still the case I
can look at (although that you assigned yourself ;-)

OpenPGP does not specify this. It is actually not easy to add another format
becuase that opens the path for all kind of attacks. Like with ELF comment
section you can do the same for any other data format. No, there is no ELF
parser in gpg and there won't be one for any other language.

Please take this to the gnupg-users ML or to the OpenPGP WG. Thanks.

Additionally to T1665 (wk on Jul 03 2014, 11:13 AM / Roundup) (outlining that a trust path to the global SSL companies
is available and thus resolving this):

https://files.gpg4win.org is verified by a certificate that is available over
https://ssl.intevation.de/ this site is "verified" by one of the preinstalled
companies. (You are hopefully aware that you just have to send them some bucks
and some unsigned mails with an @intevation.de address claiming that you are
intevation.de to get such a certificate)

We also bought a certificate for codesigning so that in Windows itself you get
an assurance that one of the >100 Root CA's in their certificate program earned
some money from us ;-)

Please check the openpgp signatures or the checksums in our release
announcements and decide for yourself if you trust us. We can just buy your
trust otherwise.

This should have been resolved a long time ago. There was a KDE bug about this
but I can't find it anymore.

I had another go at this bug this evening. I had a keyserver with reproducable
failures (while I still could use it in gpg1). And suddenly during debugging it
all changed and worked flawlessly. I was down to npth_connect and after I had
added debug output in there it began to work (and kept working after removing
the debug output again, hrmpf)

With regards to the test case from T1773 (aheinecke on Nov 26 2014, 10:35 PM / Roundup). This now (after e8c0ed7 ) returns a
dead host.

Btw. I think the error message could be improved for dead hosts.

gpg2 --keyserver hkp://127.0.0.1 --search foobar
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Should be something like "No reachable keyserver found"

Assigned this bug to me to at least provide a clearer example.

Thanks for fixing the 127.0.0.1 lookup error :)

The language designers will almost certainly return the ball by saying that it
is not their job to define signatures :-)

Elves and dwarves aside, could we have a bottom signature format that would keep
files readable for Shellscript, Perl, Python, plain text and maybe a few more by
using the last line in the file as in my example? This is the main request here.

Should be fixed now.

The next version will no longer include the generated moc files.
It's not really a patch to backport (as you requested this in your mailing list).

In quilt you can just do something like:
quilt new remove-broken-moc-files.patch
quilt add qt4/*.moc
rm qt4/*.moc
quilt refresh

That is something you need to build into your language's interpreter or into the
OS proper (for the ELF, COFF, or the shebank hack). We can't do anything in gpg
with that. It is of course possible todo that. For example many years ago, I
wrote such a system for ELF with gpg used by a tool for signing and a dedicated
verification module for the OS.

If you like to discuss this, you may want to post to the gnupg-users ML.

understood - please note I used a very recent automake in testing this
without issue, but I only have an osx platform - others may experience
breakage.

I also ran into this problem with our (intevation's) debian packaging.

Just removing the .moc files worked as they were correctly generated
automatically (as they should be).

I'll commit a fix not to include them in the dist package anymore.

This is due to a newer automake. This is not yet supported due to backward
incompatibilities since autmake 1.13. The plan is to switch to a newer automake
with the release of Debian's Jessie. See README.GIT on how to use an
alternative automake version. There is at least one other bug regarding this
problem, thus I will close yours.

As noted on the ML we do our own selection from the pool and consider only A and
AAAA records. This needs to be changed of course. Unfortunately this won't go
into 2.1.1.