For the spawn_cb, I reconsider. Having three calls complicates use, and it is actually not needed. In the case of pthread_atfork, it is needed, because fork may be used deeply in some functions. In our use cases of spawn function, prepare part of the callback can be called before calling spawn, and parent part of the callback can be called after calling spawn.

I decide use of pid_t, as there are different semantics between POSIX and Windows, *and* there is a problem of MinGW-w64. I introduce gpgrt_process_t, instead.

I updated *.m4 scripts in gogol:

I recently noticed that the old workaround by setting a kategory when it is not visible in the messagelist does not work on a default Outlook 2204 anymore. This raises the priority of this issue.

Hello, if I understand the issue correctly this issue is about saving a decrypted email as a file to a local disk and not to Outlook? We would like to save the mail as a file like a normal mail file.

There must be something special with the message. Can you save the message to a file and use the command line to decrypt it? Is there anything special with it? Is it maybe a binary and not text? Although I tried decrypting random bytes with the notepad and it worked for me. Is the message very large? Anything unusual? Or does it even happen for you when you encrypt a short text to yourself and then decrypt it again?

fixed

Hi Vincent,

Fixed

We develop many versions of pinentry, but not the one for macOS. Therefore, we cannot help you. Please contact the developers of pinentry-mac (https://github.com/GPGTools/pinentry) or the homebrew maintainer of pinentry-mac (https://formulae.brew.sh/formula/pinentry-mac).

I've got a similar patch, but I'm not sure it's any better -- I'm adding EcDSA support for cards (via gnupg-pkcs11-scd) and with this patch I can sign subkeys and data.

Note the relationship to T4195, T4826, and T4766

Ready for testing

2. In the Certify dialog the "Advanced" expander lacks a focus indicator.

Hey Werner,

I installed zlib, looking at: https://aur.archlinux.org/packages/mingw-w64-zlib

I'm going test with 64-bit default lib32 with -m32 version, looking at: https://github.com/Jesseatgao/mingw-w64-multilib

For *.m4 scripts, I pushed changes to prefer gpgrt-config with *.pc files than *-config scripts (T5034).
Before the change, it was not coherent; gpgrt-config gpg-error is preferred to gpg-error-config (if available), but libassuan-config was used if available.
After the change, gpgrt-config is used to configure gpg-error and libassuan, etc.

For the migration, preferring gpgrt-config than *-config is better.
So, I decided to change *.m4 to do that.

The problem here is how large the data to be signed is. It is an issue of protocol design. The protocols are explained in openssh/PROTOCOL.certkeys and openssh/PROTOCOL. Unfortunately, it seems that it was designed with not much consideration for smartcard use case, so, data to be signed may be longer (than the capability of smartcard).

Sadly, it doesn't work for me. But thank you.

I managed to find a way to minimize the data (less than the one on Oct 25).
And it somehow works for me.

Another thing when we define a type which represents process.
For pid_t, MinGW-w64 has a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1397787 (or https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/1456671365-21759-1-git-send-email-sw%40weilnetz.de/).
(1) GetCurrentProcessId always returns 32-bit (DWORD), so, it can be represented in 32-bit (although DWORD is unsigned).
(2) POSIX requires pid_t should be signed integer https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
(3) Original MinGW defines pid_t as int (in include/sys/type.h by _pid_t). (checked in mingwrt-5.4.2)

So what should I do now? Should I report it to OpenSSH team?

Yep. Closed now.

Meanwhile I have _some_ doubts that the v5 format is a good idea. It will introduce a lot of problems and thus a more lean way of replacing the fingerprint should be re-considered. Even if that means, we have to live with two kinds of fingerprints for a decade or so.

We won't do that. FWIW: We started to work on a 64 bit WIndows version of GnuPG.

Given that the OpenPGP WG practically decided to fork OpenPGP I don't see a reason why we should keep this bug open.

I can't see what we shall do here.