Mon, Nov 11
See also D475.
Fri, Oct 25
Thu, Oct 24
There is a growing bit of popular lore in the GnuPG community that "when keyserver operations fail, you solve that problem with killall dirmngr." I believe this suggestion is potentially damaging (the long-running daemon may be in the middle of operations for a client that you don't know about), but i suspect it is circulating as advice because it resolves the situation outlined in this ticket. For whatever ephemeral reason, dirmngr gets stuck, and fails to notice that this situation has resolved itself.
Oct 17 2019
GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.
Oct 15 2019
Sep 30 2019
Sep 20 2019
$ gpg-connect-agent --dirmngr 'getinfo version' /bye
Can you check which dirmngr version you are running
gpg-connect-agent --dirmngr 'getinfo version' /bye
thanks for the dns explanation - IMHO, there should be added something about that in the wiki
When it does not work for you on http1 either, then I guess, it's really just some outdatedness of my gpg/dirmngr and this ticket can be closed.
It does not work either. Your problem is the use of a wildcard DNS for archlinux32.org:
The test above was with gpg master but I got the same result with current 2.2:
ok, I disabled it again. btw: why do we need openpgpkey.archlinux32.org in the cert? Is this standard or did I misconfigure something?
Thanks. Here is a dirmngr log:
Sep 19 2019
I set archlinux32.org back to http2 - so you can see for yourself, how gpg fails to retrieve the key for firstname.lastname@example.org
I believe, it means, that it may fall back to http1.1 - the documentation is not clear to me on this.
A simple test however shows, that at least curl has no problems to use http1.1 or http1.0 with the http2 enabled nginx.
Does your ngix configuration mean that there is no fallback to standard http?
Sep 12 2019
To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.
Aug 23 2019
Will be in 2.2.18
Aug 10 2019
WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:
Aug 6 2019
DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.
Jul 16 2019
Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.
I see. I am also mostly testing with ntbtls so I was wondering about the report. Thanks for reporting and fixing.
While I understand incorrectness, the risk in practice is not that high. So, I put this as "normal" priority.
Pushed the change to master as well as 2.2 branch.
Jul 15 2019
Jul 14 2019
Jul 11 2019
Is this really necessary to duplicate functionality that already is provided by Web Key Directory?
With NTBTLS, it seems it works correctly.
Jul 10 2019
I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.
Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.
Ah, that makes sense, good catch. Seems this is just an issue of documentation, then.
Jul 4 2019
And of course, thanks for your fix.
Applied to both branches. I have run no tests myself, though.
Fix will be in 2.2.17