In that case could you please attach a basic log from selecting an S/MIME Mail with S/MIME disabled? Activatable under GpgOL options / logging

no, SMIME was not activated, the error still appeared and only when the GPG plugin was completely deactivated could Outlook read SMIME properly

I think there is a mixup here. I believe that you are experiencing https://dev.gnupg.org/T6192 (From 2019) which is a fairly recent regression and was discovered by our internal QA in September. As we did not get reports about this we only gave it low priority.

The first report? In history, i know, on older versions, this issue was also exist and reportet.

@gniibe: Thanks for looking into it.

I tested on the machine with:

This will go into the next release.

Follow-up in reference:
https://dev.gnupg.org/T6258

works as proposed by werner.

Please note that gpg4win 3.1 is not anymore maintained.

Please note that gpg4win 3.1 is not anymore maintained. Gpg4win 4.0.4 is the currrent release and comes with the IMAP fix. We do not have a single GnuPG VS-Desktop customer using IMAP and thus having the fix only in the next VSD version seems to be okay.

"Fix IMAP access to encrypted mails" - patch still not applied in codebase 3.1.25 ...

Go ahead if you want to do that.

Surely not. We just take the key from those certificates. Note that ssh-add merely imports a key permanently into gpg-agent's key store.

Thank you. I am glad that it is already resolved.

Will this be in the next release of libgcrypt?

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.