In T6195#163175, @werner wrote:

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

I agree. We have to get rid of auto check trustdb and such stuff. I always found that impossible to program around because it either takes a long time (check-trustdb) or it might return invalid results (no check).
The solution for this is keyboxd.

If you run gpg --export-ownertrust you will notice that the trust has been set to ultimate (value is 6). However, due to the no-auto-check-trustdb in your gpg.conf that will valeu will only be shown after running gpg --check-trustdb. The value shown in the key listing is the computed value and the computation is done by --check-trustdb. I don't see a bug here.

Pushed changes.

The export/backup of the secret part of S/MIME certificates has been fixed with T6189: Secret key backup of S/MIME certificate creates bad result. An exported certificate should now be imported without problems.

Now "BER error" is reported, if the user tries to import a .p8 certificate. (The certificate exported by Kleopatra wasn't stored as PKCS#12, but presumably as PKCS#8 which gpgsm cannot import. See T6189: Secret key backup of S/MIME certificate creates bad result.)

--import [files]
       Import  the certificates from the PEM or binary encoded files as well as from signed-only messages.
       This command may also be used to import a secret key from a PKCS#12 file.

BTW, gnupg/doc/DETAILS tells that the fingerprint is optional:

Pushed the fix for GPG_ERR_INV_ENGINE.

gpgsm may emit S IMPORT_PROBLEM 1 (with no fingerprint information) when it cannot find valid fingerprint.
I think that this case should be handled correctly by GPGME, not returning GPG_ERR_INV_ENGINE.

Ok. That is about the Invalid Crypto Engine. But this does not explain why a .p12 export via Kleopatra leads to this error when we export a valid certificate. The same thing I do with Kleopatra on the Command Line works:

The error is generated in parse_import in gpgme/src/import.c:

if (errno || args == tail || *tail != ' ')
  {
    /* The crypto backend does not behave.  */
    free (import);
    return trace_gpg_error (GPG_ERR_INV_ENGINE);
  }

The more relavant error is that there is no status output on failure which is what gpgme uses (due to double forking).

gpgv returns success iff the signature is valid. That is the whole purpose of this tool.

I have introduced this hint exactly because it's impossible to describe the rules automatically.

These hints are taken from the help.txt file.

gpg-agent passes to pinentry a short and a long hint for the passphrase constraints (see constraints-hint-* in pinentry.texi). If these hints are set, then pinentry shows them even before the user has started to enter a passphrase. The error message can then simply be "Read the hint, stupid!". Just kidding, of course.

Can you please give a more detailed example with regedit files to demonstrate that?

Can't we get them from the help.txt file? Putting a tooltip into the pattern file would be an option but needs substantial changes,

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