Oh yes, the usual import statistics should be shown here.

Are you sure you are using SSH user certificates for SSH authentication? I have trouble with SSH certificate authentication instead of public-key authentication.

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.

I am using this many years now without any problems. Also my collegues and many other folks I know. Thus the question is how your system differs from commonly used systems.

I have tried the stable version (2.3.8). Sadly, it doesn't work. 'agent refused operation' again. And I think it may have nothing to do with OpenSSH certificates because NIST256&384&512 keys do work in this situation.

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

We do not support OpenSSH certificates but ignore such requests. However, the keys from the certificates will be imported correctly. You should use the stable version of GnuPG (2.3.8) and not the LTS version 2.,2.

This is the first report we have on such a problem despite of hundred thousands of users. "Triage" means that we need to look at a report to check its priority.

@werner , why set to "needs triage"? At this moment plugin must be disabled if customer read crypted SMIME E-Mails. So it is critical. disable checkbox "SMIME" will not work correct. Enable "SMIME" will only encrypt as Text, but some E-Mails have HTML.
We have this issue on all systems (Windows 10 and Windows 11)

I tend to close this as a duplicate.

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.

Applied also in 2.2 branch.

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.

Renamed bug due it being incorrect to assume this was a bug with libgpg-error. Turns out that a simple patch to g10/Makefile.am in GnuPG 2.2.40 LTS source fixes the linking error. Patch that fixed build for me is attached, which basically puts -lws2_32 in the correct location for builds with the new libgpg-error 1.46 version.

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)".

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

It seems to me there are two separate concerns here:

Thank you, confirmed. Pushing the fix.

You need to assign a drive letter.

is there any news for gnupgp 4.0.4 release with gnupg 2.3.8?

My suggestion is to clearly state that there is a direct Key Signature with an expiration date. Another feature would be to add a separate command to modify Direct Key Signatures. However, the latter has the problem that it help with proliferation of such signatures and other OpenPGP implementation will run into other problems. Thus for the whole ecosystem such an option is might not be a good idea.

Thanks for looking into this!

Direct key signatures are rarely used. IIRC, we implemented that the same way PGP did it.

Fixed in 1.6.1.

Fixed in 1.6.1.

One more nit regarding to the test is the format string for size_t which was using %d instead of %zu. This is fixed by the attached patch:

Hello,
I'm having the same issue here, and as I've an image in the signature of my emails the signature is not visible at all when I sign the messages.
The image attached seems to be well included in the attachments and the image is readable.
Thanks,
isundil

Yes, that's probably right. I talked to the vendor and they were nice enough to send us specs and samples. However, without a strong business case support for these cards we can't prioritize this work.

I am attaching one last log I have while trying to use the SC-HSM and using the debug options mentioned. From what I understand, the keys and certificates are recognised by scdaemon, but, for some reason, they don't show up in gpg --card-edit --expert or in Kleopatra. Having AES symmetric keys also causes the PrKDF to show up as invalid.

Also applied to 1.10 branch.

Patch applied to master, thanks.

In T6218#163787, @gouttegd wrote:

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Yes. Scute relies on those to interact with the token.

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

One nit that I overlooked initially is the memory leak, which is fixed with the following patch:

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

Let's don't forget that we need to have a sig_class replacement.

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

This is not easy to fix because it would break the GPGME API. Here
are the values we can expect:

I assume this is gpgme master. Please write proper bug reports.

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.

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

That sounds quite cool.

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)

Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.

I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.

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.

Which version of Scute are you using?

The specs https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf page 10 says specifically:

Using Scute as a drop-in replacement doesn't currently work. Perhaps my config needs more adjustments than just:

module = /usr/lib/x86_64-linux-gnu/scute/scute.so

I've tested the different hw implementations (amd64, arm64, s390x) and they are all ok.

Thank you for your report.

Yes, I meant to use Scute as pkcsc11 module for pam_pkcs11. Thanks for explaining more verbosely what I meant.

I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)

My poor old laptop - its RAM will now have a hard time to run the huge tests ;-)

The test looks good. I hope I changed the API in all the hw optimized implementations.

I'm not sure what you mean with using Scute as PKCS#11 provider instead of pam_pkcs11, as pam_pkcs11 is not a provider but a user of PKCS#11

There is a reason why pcsc-shared is not the default ;-). Please try using Scute (best the t6002 branch until it has been merged) as pkcs#11 provider instead of pam_pkcs11. And you should of course use the stable version of GnuPG and not the LTS (2.2).

Fix looks good to me. This could be tested with new long running test (tests/hashtest) that would allocate 4GiB+ pattern block for inputting to gcry_md_write.