Small correction: We don't have replicas of our code signing key. I mistook this with out Authenticode signing key.

In general I use my standard ed25519 signing token for all software. However, GnuPG VS-Desktop is signed using a Brainpool key named GnuPG.com (stored on a smartcard with 2 replicas) for the simple reason that it does not raise questions when ppl update their GnuPG VS-Desktop and run into a non-compliant key.

In the situation of a certificate about to be expired in the cache:

Thanks, @gniibe -- i agree that this change to put_cert should be helpful, when encountering a certificate that is already invalid.

rejecting an intermediate certificate too.

Pushed the change of mine to master, since I can confirm that it results validate_cert_chain working better, because of put_cert's rejecting an intermediate certificate too.

@dkg: Thanks for the detailed description of the problem.

Thank you @dkg for the analysis. Unfortunately, the certificate cache is hashed by SHA-1 FPR, so, I think that it is a bit difficult to implement moving certs "front" / "back".

Thanks for the followup about R3, @mpilgrem! Looking at your logs in more details, and the source code for find_cert_bysubject in dirmngr/certcache.c, i think i see what the issue is. It's slightly more subtle than not terminating early if a known trusted root can validate a truncated chain.

@mpilgrem, i'm glad that removing the DST Root CA X3 from your windows control panel worked for you, but it still doesn't seem to be a reasonable fix from a GnuPG user perspective

The PKCS#12 import was a late add-on because I consider P#12 to be a nasty and insecure format. Unfortunately it survived and is now the mainly used interchange format. Eventually we need to improve things here. However, ppl should use smartcards for S/MIME.

If you use an IP address there is no server name and thus a) TLS can't check the name and b) virtual servers won't work. But as you stated this is not the problem: With rGb231959728a0056 (T2924) https is handled in another way than hkps.
Now, that change was only applied to KS_GET and not to KS_SEARCH. This is kind of correct but shows this surprising behaviour: For the preferred keyserver we really want to do a plain fetch and don't have all the hkp ip/name mapping we do.

Doing the same thing on my second PC, I can be more precise:

I'll reopen this ticket here, since the underlying issue is not quite resolved yet as @dkg helpfully outlined above.

Thank you dkg. I am new to 'certificates' generally - and a little knowledge is a dangerous thing - but this is what I did:

@mpilgrem: in the meantime, for connecting to keys.openpgp.org, which *has* cleaned up its certificate chain, you might also want to try killing your dirmngr process, and/or cleaning up the data in .gnupg/dirmngr-cache.d/.

Basically, the website in question (e.g. https://openpgpkey.gnupg.org/, which exhibits this problem) serves up three certificates:

Fixed in 2.2 and master. Did a couple of manual tests using 2.2 on Linux. gpgsplit comes handy to add a couple more tag-3 packets (same algos or one patched to camellia for the negative test)

This also points out that the cipher algos and modes of the symmetric encrypted session key packets where never checked for compliance. We only checked the compliance of the bulk encryption cipher algo.

This was added in b03fab09e188f7bb10237d4f20455e4026737e4e

Oh, there appears to be a reason for that. In line 699 of mainproc.c:

/* Symmetric encryption and asymmetric encryption voids compliance.  */
   && (c->symkeys != !!c->pkenc_list )

Fixed with commits
rGeb675fbc4e4db52c3276bc0748b49df8a213fbc4
rG890e616593af5d1e0f2eb932768205ef90928e5e

Yes, I think that makes sense in the way that we want to provide the best user experience for our own users even if they communicate with communication partners which creates problematic keys.

In de-vs mode we could change the implict algorithm from SHA-1 to SHA-256. That should solve the problem.

@werner Could these two patches could be backported to 2.2? These changes give same level of performance increase in 2.2 as seen in 2.3.

Fix will go into 2.2.37 and 2.3.8.

There won't be any semantic changes for obvious reasons.

@gniibe Thanks!

In the repo, for all related software, it's done.

Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.

Thank you.

It's in 2.3.7 and 2.2.36.

It's in 2.3.7.

In gnupg/common/ttyio.c, the function w32_write_console does:

• Call WriteConsoleW, and when it fails, it calls
• WriteConsoleA

ACK. P[ease add it also to 2.2.

Even if it is only a single case (of old version of Wine), I think that it is worth to add es_fflush when writing to file.

Looking illumos-gate, Solaris variants have no issues.

Wine 5.0.3 (on Debian bullseye) fails.
Wine 6.0.3 Debian testing does no failure.

I created minimized test:

Closing in favor of D556.

iirc, we use ftruncate for ages now. The problem with the name ftruncate is that it looks to similar to the stdio functions. But sure, things should be flushed first.

Compressed packets in detached signatures and/or certificates have never been permitted by any version of the standard.

In D555#5569, @werner wrote:

Sorry, there is no padding packet in OpenPGP. Please do no try to push ideas from that crypto-refresh-06 thing into GnuPG. We continue to follow the last draft with consesus, which is rfc4880bis-10.

In T6031#159248, @werner wrote:

{please add comments instead of adding the description - a changed description makes it hard to understand follow up comments. I will change the title, though for clarity.]

Sorry, there is no padding packet in OpenPGP. Please do no try to push ideas from that crypto-refresh-06 thing into GnuPG. We continue to follow the last draft with consesus, which is rfc4880bis-10.

The length limit of the signature sub packets are not reasy to pre-compute. Better to have a fatal error than a corrupt message. I am not sure whether we want to change this to a regualar error message - at that point we anyway need to stop.

Reopening as it appears this issue was closed based on an incorrect understanding of what it is.