In T4060#190972, @werner wrote:

We need a way to pass --known-notation to gpgme_op_verify

We need a way to pass --known-notation to gpgme_op_verify

Also done for 2.2.

To align the default expiration time with the BSI approval and other related software we change this now to 3 years.

The introduction of --override-compliance-check actually hid the real
cause for the signature verification problem in de-vs mode for the
Ed25519 key. The real fix is to handle the EdDSA algorithm in
gnupg_pk_is_allowed.

Release quite some time ago.

Thanks !

A real fix will be in the next gpgrt release

In T2671#158357, @werner wrote:

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

We need to do this also for CHANGE REFERENCE DATA - however, there should be an extra option so that we can debug this despite of the redacting.

Shall we really backport this to 2.2 given that ECC for S/MIME is in most cases a smartcard thing?

Fixed for master but not yet tested.

works as proposed by werner.

The latter. Detecting mail addresses with regexp is anyway a kludge and we have more stringent code to detect mail addresses in a user-id.

@werner i'm not sure i understand what "easy to enclose them in angle brackets just for comparison" means.

We already detect mail addresses for different purposes and thus it will be easy to enclose them in angle brackets just for comparision.. Almost all trust signatures out there are created by gpg and used to restrict the mail domain. No need for different regexp. See also the comments in the code related to the history.

Ah, sorry, I did my own changes before looking T6244#164317

Pushed the changes to 2.2 and master.

Thank you for your report. The issue is handling of static linking in GnuPG.

It will be hard to fix this. GnuPG supports exactly one class of regular expressions: something bracketed between "<[^>]+[@.]" and ">$" . Even if the next release of gpg supports more regular expressions, gpg will have to wait years before it can start emitting different regular expressions for scoped tsigs by default.

I recommend, when making a User ID with only an e-mail address, to populate the User IDs by wrapping it in an angle bracket, rather than just leaving the raw e-mail address. It's not just the regexp matcher -- there are other pieces of OpenPGP software that won't recognize a raw e-mail address in a user ID as an e-mail address. It also makes it easy to distinguish such a User ID from a User ID that is not at all an e-mail address.

Thank you for your report. IIUC, your log is the build log of GnuPG 2.2, so, I put the tag "gnupg (gpg22)".

I believe https://dev.gnupg.org/T6239 also applies here. It would be great if the fix could be backported.

Indeed, the status line should not be emitted in this case. Thanks.

With a gcrypt not claiming compliance you should not get the status compliant or not but GnuPG should error out with forbidden.

Justus, you should know how to write a proper bug report. Please do that and don't just paste some more or less random output here with just hint that Libgcrypt is not compliant. tia.

works now

Thanks for testing. I guess I will do a new release.

Applies cleanly and fixes the crash. 👍

For master (2.3) the fix is not needed due to another way the code works, but having a more robust function is always good.

You may try the above commit - if should apply cleanly to 2.2.37.

You are right. This due to your old binary private key (stubs). Otherwise you would at least have one item ("Key:"). I need to see what do do about the release. Maybe a tool to update the key files would we a good workaround.