Applied also in 2.2 branch.

This also affects 2.2.40. Will the fix be backported there? Thanks.

Thank you, confirmed. Pushing the fix.

This is a debug option; I see no use case for this.

Add --expert and use a decent version of GnuPG. 2.2 is our long term support branch and is not the current stable production version (which is 2.3.7)

Perhaps --full-generate-key should provide more algorithm choices, then, e.g. ed25519?

Sorry, this as been discussed ad nausea. We try our best to help people not to use useless and harmful (e.g. performance of the WoT) algorithm choices.

Yes I do understand Windows XP is not supported. Just in case it is a minor problem that is easy to fix and will not cost you much effort. I'd like to add more information: I do not change
%LOCALAPPDATA%. There is no such environment variable. A similar environment variable is:
APPDATA=C:\Documents and Settings\myname\Application Data
I do set GNUPGHOME=E:\key, which I think should be allowed because I do not want my personal info be stored in system drive.

We should close this. The recent fix in 2.2 and the forthcoming 2.3 does everything we want. In the meantiime or if further problems turn up, --ignore-cert is a good workaround.

This is a support question and not a bug. You should ask such questions on the channels for Gpg4win, which does the Community support for GnuPG on Windows: https://www.gpg4win.org/community.html

No, it does not matter.

E:\key>gpgconf --list-dirs
sysconfdir:C%3a\Documents and Settings\All Users\Application Data\GNU\etc\gnupg
bindir:C%3a\Program Files\gnupg\bin
libexecdir:C%3a\Program Files\gnupg\bin
libdir:C%3a\Program Files\gnupg\lib\gnupg
datadir:C%3a\Program Files\gnupg\share\gnupg
localedir:C%3a\Program Files\gnupg\share\locale
socketdir:E%3a\key
dirmngr-socket:E%3a\key\S.dirmngr
agent-ssh-socket:E%3a\key\S.gpg-agent.ssh
agent-extra-socket:E%3a\key\S.gpg-agent.extra
agent-browser-socket:E%3a\key\S.gpg-agent.browser
agent-socket:E%3a\key\S.gpg-agent
homedir:E%3a\key

The "sysconfdir" "C:\Documents and Settings\All Users\Application Data\GNU" does not exist actually. Does it matter?

I just fixed a bug related to the DP. That might be related. See rG0c8299e2b56ef2e1

That particular bug seems to have been solved a long time ago. I stumbled upon up while fixing a DP bug today.

To clarify that I meant that the underlying problem is our current keylisting speed in Kleopatra I have opened T6206.

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 )