Lot's of things changed in the meantime.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 26 2023
HKP keyservers are anyway out of fashion and thus we won't put anymore effort into his part of the code.
Lot's of changes since 2.4.
Jul 4 2023
Jun 22 2023
See for T6545 for a new request to support IDP.
Jun 15 2023
I have now disabled the rewriting in the 2.4 branch. Those who want to keep the old behaviour may add
May 3 2023
I will review the issue. A likely outcome will be to follow your suggestion but to add an option for the old behaviour to avoid further security discussions.
Apr 21 2023
Apr 19 2023
Apr 16 2023
Apr 14 2023
Apr 5 2023
Apr 3 2023
After diligently reading the code I realized that this bug has long been fixed. For reference here is the patch I wrote to extend dirmngr_ldap during my tests:
Mar 29 2023
This has been solved loooong ago.
Mar 21 2023
We need to extend dirmngr_ldap.c to take a list of attributes to return. We already have the --multi option which returns all attributes for latter filtering by the caller but the specified attr is also used and thus dirmngr's start_cacert_fetch_ldap() retruns only the requested caCertificate.
Mar 17 2023
Hello All,
Feb 27 2023
The code has meanwhile been reworked and the mentioned test server is not anymore available
Jan 19 2023
Dec 5 2022
Nov 17 2022
Oct 11 2022
Sep 29 2022
Applied and pushed the change from @joeyberkovitz in rG3257385378bb: dirmngr: Interrogate LDAP server when base DN specified..
Sep 26 2022
BTW, I have also in mind to use an AD entry to figure out the used keyserver. It turned out that people don't like to modify the schema of their AD but instead use a separate LDS.
To proceed, I pushed an initial part as rG993820c31521: dirmngr: Factor out interrogate_ldap_dn function., which doesn't change any behavior.
Then, the point of the change will be clearer.
Sep 22 2022
Sep 19 2022
What is a partial CRL; I have never seen that and IIRC the specification for that was not complete.
For what it is worth, I think that my patch is more standard compliant then yours because it checks if there is a partial CRL.
I think 289fbc550d18a7f9b26c794a2409ba820811f6b3 implemented this wish from 2016 :) @werner please read the full report and then close it as fixed if you agree. I find it a bit funny that we both came independently to the same conclusion, that it should be handled differently even if the standard says otherwise. Because the behavior from the standard does not make sense and is in contradiction to other parts where it says that each CRL must contain all revocations.
just checking in about getting this patch reviewed
Sep 16 2022
That particular bug seems to have been solved a long time ago. I stumbled upon up while fixing a DP bug today.
Sep 14 2022
Awesome, thanks all! From an end user perspective that would be a perfectly acceptable outcome, the warning just serves to confuse people. Appreciate the help!
I have created the spin-off T6202: Kleopatra: Suppress errors of WKD lookups to deal with not bothering Kleopatra's users with error messages when doing a WKD lookup in the background. This task is for improving dirmngr.
Jul 29 2022
Jul 26 2022
The fix has been merged to the 2.2 branch.
Jul 15 2022
In T6067#160368, @vitusb wrote:Due to https://dev.gnupg.org/T5725#153224 ("The fingerprints are needed by Kleopatra as unique identifier for keys."), is this still implemented in that way ?
What i don't understand is ...
Jul 10 2022
Due to vacation the review may take some time.
Jul 8 2022
It will hopefully be fixed in 2.2.37.
Hello,
thanx for fixing this issue ...
Any chance someone is able to review the posted patch?
Jul 7 2022
Jul 5 2022
Let me know how best to submit it
I tried to submit the below patch to gnupg-devel@lists.gnupg.org, but get an Unrouteable address error. Let me know how best to submit it
Jun 29 2022
The first ideas sounds best to me. Patches please to the mailing list.
Apr 28 2022
Apr 25 2022
Was fixed in 2.3.5
Apr 20 2022
Apr 14 2022
We have not seen this problem anymore in recent versions. Thus closing.
We have a solulion for this bug. For further improvements we will use T5882.
Mar 30 2022
Mar 28 2022
Good idea. Thanks. Goes onto 2.3 and 2.2
Mar 25 2022
Confirmed to work, thanks!
it still shows the no certificate or invalid encoded error message:
Mar 24 2022
I gave it a try. It works now, but it still shows the no certificate or invalid encoded error message:
Thank you. Confirmed.
Mar 21 2022
Actually this is pretty obvious; we better ignore such misbehaving servers.
Mar 17 2022
I think that the particular issue of Let's Encrypt Certificate was handled correctly already.
Mar 16 2022
Mar 10 2022
Gook luck on Solaris with this suggestion ;-)
Gook luck on Solaris with this suggestion ;-)
For the record, the typical response to "it doesn't work" support requests for keys.o.o still comes down to killall dirmngr.
Feb 28 2022
do you mean "dirmngr on Windows choses this one"? As in my mental model, dirmngr only loads all certifices from the windows stores on startup, but not during operations when requests come in (I maybe wrong though, I did not inspect the source code on this).
But in Windows 10 I get nothing in the certs.log file.
Feb 26 2022
In T5639#155478, @werner wrote:echo BYE | dirmngr -vv --server 2>certs.logLists all certificates
Feb 25 2022
echo BYE | dirmngr -vv --server 2>certs.log
@TheParanoidProgrammer this looks like a very good and thorough analysis, thanks again!
Feb 24 2022
Ok, I managed to find 48504E974C0DAC5B5CD476C8202274B24C8C7172 via Powershell. It was in the CA store of my non-privileged user and since I always checked the certificate store as administrator it did not show up there. After removal of this intermediate certificate I am able to use hkps://keyserver.ubuntu.com.
Ok, so order of loading is not a problem since the cache does not store them by insertion order, but instead indexes them by the first byte of their fingerprint.
So, I think the problem here is that the expired intermediate certificate (48504E974C0DAC5B5CD476C8202274B24C8C7172) is somehow loaded in Windows and since its fingerprint's first byte is less than the server-supplied intermediate (A053375BFE84E8B748782C7CEE15827A6AF5A405) Windows chooses this one. I can see that the expired intermediate certificate is indeed loaded on Windows if I increase verbosity of dirmngr logs. However, I am still unsure where this certificate lives. The log says it comes from the "CA" store, but searching for it visually or by fingerprint search in Windows Certificates Snap-In (MMC) does not let me find it.
I will keep looking, but if you want to reproduce in your VMs, I suppose adding the expired intermediate certificate and the expired root certificate to the system store should make this reproducible.
@TheParanoidProgrammer thanks for investigating further. It is highly appreciated!
On a side note, it turns out that Ubuntu Maintainers ship gpg with GnuTLS dynamically linked, so that's why I went down that road first. I compiled gpg from source for Ubuntu with ntbtls for further tests. Interesting insight is that find_cert_bysubject returns different certificates on first try on my Ubuntu Machine compared to my Windows 10 Machine:
Feb 23 2022
Ok, I may see three potential problems in dirmngr->validate.c->validate_cert_chain(), but it may also be my limited familiarity with the gnupg source.
- Here we leave the certificate validation loop at the first trusted root certificate, even if it is expired as we only mark this fact for later evaluation.
- Here we seem to only ever go up the chain, never sideways as is the case in the original patch for this bug.
- And probably most impactful, here we fail the whole validation if any of the previously checked certificates is expired, so that even if we would fix the second point by checking sibling certificates, we would still get an overall failure.
What I wonder is: In a number of tests in our machines (mostly virtual machines), the TLS access to keyserver.ubuntu.com does work. I have yet to see a VM where it does not. So there must be a difference.
Not a solution yet, but some more insights.
Starting from @NoSubstitute 's log output and from @bernhard 's statement that we use ntbTLS I verified that my dirmngr.exe was indeed compiled with NTBTLS 0.2.0. I did so by running strings "C:\Program Files (x86)\GnuPG\bin\dirmngr.exe" | grep TLS which returned "This is NTBTLS 0.2.0 - Not Too Bad TLS" among other strings. I also grepped for some debug strings introduced in newer commits to verify that the NTBTLS version used is not the current HEAD of master, but at least some commit before 64f895dba734802662cbb81b64cd0b4af198ee71. I will just assume it is the actual 0.2.0 release for now.