Okay. So, I removed gpg-error-config, updated libgcrypt/m4/gpg-error.m4, and then rebuilt configure. And, gcrypt configures and builds.

Thank you for the information.

Actually, it looks as if libgpg-error-1.46 already has that fix.

Thank you for your quick reply.

Yes, it is on macOS.

From the information in gpg-error.pc, I think it's on macOS.

Pushed rGe4ac00960c94: po: Update Simplified Chinese Translation..

In order to remove the SHA-1 algorithm in Arch Linux package keyring, I need to resign one of my sub keys but the backsig (0x19) remain in SHA-1 as reported here.
I didn't find any solution with gnupg to update it since this bug report was opened in 2020. Do you plan to address this in a near future?

T5683: Deprecation of gpg-error-config

Contents of /usr/local/lib/pkgconfig/gpg-error.pc:

Manually installing gpg-error-config in /usr/local/bin allows libgcrypt to configure and build.

Hi Werner,

An old version is still installed and the libgpg-error-0.dll could not be replaced. Make sure that you deinstalled old gpg4win versions and other gnupg versions. The file version of the DLL shall be 1.46.x.x.

I see. I understand the use cases for POSIX to keep some file descriptors.

I don't have common.conf but I do have pubring.kbx. I meant I plan to remove that key from my keyring because it's like a decade old and expired, but I figured maybe it was somehow related to this bug since it's the last key shown, so I've left it in.

Are you using the keyboxd ? ("use-keyboxd" in common.conf) or is this using the default pubring.kbx.

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

In regards to this issue, we were also notified that the MD API using gcry_md_setkey() can be used to calculate HMACs and it does not have the needed input key length limitation. From the discussion here I read that we would like to keep the internal usage still available so my proposal would be to to add similar check as in gcry_mac_setkey() into the above function. Together with the revert, it is available in the following merge request:

without this list we don't have an option to keep file descriptors open; its not just stderr but for example log files and descriptors which pare passed by other meands than libassuan functions.

PS
The problem is also active, if I send an encryptet (not signed) message to myself.
If I get mails from other people, wich are encryptet using smime and the same certtificate and signed by the sender, there is no problem. GpgOL works fine here.

In T6039#164435, @gniibe wrote:

I read the document (SP 800-131Ar2) again. I think that it would be irrelevant for PKDF2, because it's password KDF, not deriving additional keys from a Cryptographic Key.

• assuan_pipe_connect and internal _assuan_spawn

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.

I read the document (SP 800-131Ar2) again. I think that it would be irrelevant for PKDF2, because it's password KDF, not deriving additional keys from a Cryptographic Key.

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 causes ACVP tests to fail, so apparently the assumption that passphrases must be at least 14 bytes was incorrect. ACVP testing tests values larger than 8 bytes. I'll try to clarify whether that's a limit we need to enforce, or just what NIST wants to test. In any case, we will probably have to revert this.