You'll have to talk to the people you got pinentry-mac from.

No, these are simply the technically available algorithms. I'll see what I can do.

I don't know about pinentry-mac but it seems to be another name for
one our our regular pinentry variants.

Enable the setting Create OpenPGP encrypted files with ".pgp" file extensions instead of ".gpg in Kleopatra's Settings.

We provide lots of different flavors of pinentry, but we do not provide pinentry-mac. You'll have to talk to the people you got pinentry-mac from.

Rename the file and you are done.

Thanks for diving into the history of that code.

Here is the backport to 2.2:

In the original code, register_trusted_keyid is used in keygen.c, so that it updates user_utk_list, thus, will be into utk_list.
This should be done, by adding the keyid to utk_list directly.

Things have been a bit buggy here (probably, since the beginning).
In g10/trustdb.c,

Let me clarify:

• It was on 2003-11-01 (ChangeLog is on 2003-10-31 probably in US): rG5c37fd90bf81: * trustdb.h, trustdb.c (register_trusted_keyid): New. Adds a keyid to the

I found this post when I was searching everywhere for a solution, and I was delighted. I've recently been trying to upload GpgFrontned in the Apple Store vs Microsoft and I'm having some trouble.

I went through the documentation related to FIPS and updated some wording to match reality. It will probably require still some more work.

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.

Yes, we should introduce an INDICATOR_KDF thing.

The primary version of that script is in libgpg-error. Thus it needs to be fixed therefirst.

Thank you, @gniibe ! i'm applying your change to the debian packaging as 1.43-2. i'll let you know if it doesn't satisfy the folks trying to crossbuild debian on top of musl.

Thank you.
Applied.

Patch applied, doc updated.
No change of FSM diagram.

I pushed the change: rC383866f014f2: cipher: Keep original behavior of Key Unwrap when not extended.

Thank you for forwarding from Debian.

Thanks Werner! As I'm on NetBSD I was able to use ktrace instead, and you can find the output at https://termbin.com/zm2c. (It expires in 1 month. Let me know if you would like me to paste the full output here.)

That seems to (mostly) work partially fix PowerShell pipeline output at least:

Oh, I' sorry - my fault. I searched in ...\GnuPG\bin instead of ...\gpg4win\bin

We use GetConsoleOutputCP but fallback to GetACP if the former fails. For some reasons one of the functions seems to return 437.

Given that you are already using libgcrypt 1.9, can you please try gnupg 2.3.4.

That is annoying enough that we should do a new release. I close this bug, though.

See T5758: scd: loop forever with reader_port, when open_pcsc_reader failed. Yes, the workaround is not to set reader-port.

The previous comment should have come to the T5600. Sorry for the noise.

Sorry for resurrecting the done task, but I got a message from @pmgdeb who noticed there is mismatch between parenthesis in the --with-fips-module-version help string. The attached patch fixes the issue and add proper help text.

Ubuntu have been syncing since 7th December: https://www.mail-archive.com/sks-devel@nongnu.org/msg07174.html

Ubuntu have been syncing since 7th December: https://www.mail-archive.com/sks-devel@nongnu.org/msg07174.html

Why the Ubuntu server? AFAIU it does not sync with other servers and it has some tained pubkeys (which is both fine as a choice of this service, it just does not seem to fit the purposes best).

Sorry for resurrecting the done task, but I got a message from @pmgdeb who noticed there is mismatch between parenthesis in the --with-fips-module-version help string. The attached patch fixes the issue and add proper help text.

I am tending towards wontfix. The reason is here that the sender attempts to send HTML with inline pgp. Which is not supported. Then that HTML apparently tries to be mutlipart/related which is not supported for inline PGP. Then it would require us to correct a wrongly sent content type of the inline attachment so that outlook does not interpret it as a png. And in that Format it could even be that Attachment1.pgp is not encrypted but instead png data, as the content type indicates.

For the next release I'll change the gnupg.net mappings to use the Ubuntu server also for non-TLS connections.

I have just checked both the installation script, which still installs gpgme-json.exe and the gpg4win-4 installer downloaded from gpg4win.org gpgme-json.exe is properly installed under <instdir>\bin gpgme-json.exe and under bin_64