You need to handle them in a correct way. Just checking with gpg is
not enough because you don't know what has been signed. You need to
look at the signed data which gpg gives you by using the --output
option. And there you see only the signed data and not the extra
"aaa" you added after having signed the plaintext. It is not
different from adding stuff before the -----BEGIN PGP SIGNED ... line.

In T6272#165067, @werner wrote:

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

works as described by Ingo

works

The distinction between reader and card is not easy and PS/SC is also not helpful here. The user needs to resort to trial and error. With 2.3 things are much easier because we do not need to select the reader anymore.

works

Thanks. There should also be SPDX indentifiers everywhere.

works

Examining again, I realized that the current spawn API (not published yet, only available in libgpg-error master) is not that useful in general (or difficult to use), while it works somehow.

In T5931#165009, @alexk wrote:

A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:

KexAlgorithms -sntrup761x25519-sha512@openssh.com

For me ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com ... does work as well.

works as advertised

Fixed, to be released with Gpg4win 4.0.5.

A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:

AFAIK, Microsoft stated that the value of a HANDLE will always fit into a DWORD; i.e. only the lower 32 bits are used even on a 64 bit Windows.

Now, we implemented fd passing on Windows in libassuan.
Note that the process identifier (represented by DWORD) and handle for a process (represented by HANDLE) are different things.

On the command line using:
gpg -o output.txt --decrypt "yourfile.asc"

Here is the change of GnuPG to use new spawn functions from libgpg-error:

Merged PIPE connection part into master.

ready for testing

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,