the current code in dirmngr applies @kristianf's CA whenever the keyserver hostname is the default hostname.
But if the default ever changes away from hkps.pool.sks-keyservers.net (e.g. if a distributor patches it), then it is inappropriate to permit @kristianf's CA to authenticate it.
I've just pushed 1c9cc97e9d47d73763810dcb4a36b6cdf31a2254 to the branch dkg-fix-T4593
If the default keyserver is not hkps.pool.sks-keyservers.net, then @kristianf's CA certificate has no business certifying it.
It would be a security vulnerability if we were to unilaterally add, for example, Turktrust's CA to the list of trusted authorities in some circumstances that did not reflect any specific knowledge that we expect Turktrust to be the authority of record.
As such, this is also a security vulnerability. it is especially relevant as we are starting to see distros patch out the default keyserver, and we already have one instance of them doing that without noticing that they'd left open this gap.
I'm reopening this because it is clearly the right thing to do to avoid further problems, but I'm frankly tired of fighting over every change, especially in cases like this when you offer no explanation for rejecting what is a small, obviously correct fix.
I'm trying to help this project be useful and safe for more people. Do you want that help or do you want me to give up?
Come on, if someone changes the software and breaks it, it is their's fault ant not ours. The whole thing on which keyserver and certificate to use as been discussed ad nausea in the past. Given all the problems with the keyservers I do not see a reason to change it right away to a state we had before. Keyserver code is pretty hard to test and has thus always been prone to regressions.
(I guess we should have a phone call)
We're writing free software, which we know that people use and modify downstream. if we know that the software has a particular sharp edge that people who are modifying it are likely to cut themselves on, we have two options:
One of these choices seems more responsible than the other.
In our community, upstream is widely considered the authoritative source for a project. Adoption of this security fix by upstream (even before a release) signals to any downstream that this is a correct and sensible modification. Rejection of the fix by upstream is likely to cast some doubt for some downstreams as to whether they should use it, despite its being correct. I can't imagine why an long-standing free software project with an experienced lead developer who is interested in responsible maintenance would reject this.
I did my best here to reduce the size and scope of the change so that it had nothing that could possibly be objectionable.
For example, i did not include changes that would have made the default keyserver settable with ./configure --with-default-keyserver=$foo, because it had clearly not been done that way originally (i don't know why) and i didn't want an argument about whether it was appropriate as a ./configure option to distract from getting the specific security fix in place.
Nevertheless, it turned into an argument. This is unfortunately a pattern with working in this project, and i don't think i'm the only one who has experienced it. I don't know whether i am lucky or unlucky that i am stubborn enough to persist in trying to fix things here.
I'm willing to have a call if you're interested in having other contributors on this project.
I should add that i don't really care whose fault it is if the software is broken by some downstream. if it harms any users, and we can fix it, we should fix it, especially if the fix is easy.
But please, @werner, don't comment further on this (relatively minor) bug report. T4393 is significantly more important, has even more of a security impact on users (as it affects ability to retrieve revocations from uid-less keystores), and has seen no response from you or anyone else upstream since @Valodim sent his DCO to the list nearly two weeks ago. If you're going to spend any energy responding to security concerns or to external contributions, please prioritize a response to T4393.
Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.
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.
Now this issue was closed and the patch rejected, with no explanation whatsoever. I don't understand this.
@werner Would you care to explain your reasoning?
Just reading this issue in detail.
In core it is about the case that someone who changes the changes the fixed default DIRMNGR_DEFAULT_KEYSERVER into something else like Debian currently does, finds out that there is a second place in the code, which would need a change to make the first change perfect in case no CA list is otherwise configured by the user.
I can understand Werner's reasoning: Someone changing the code should be responsible for changing all relevant places.
My thinking is: it is still reasonable to have
a trusted CA in there as fallback, even if the default keyserver would be changed in the code. And changing the code means testing the new code, there is some code attached with it.
So what we are talking about here is to make it a little bit easier to change the default keyserver in the code. I can understand that this is priority low as there are many other much more interesting improvements to gnupg's code possible.