I fixed the title, because it is not a Windows only issue.

The mentioned "g10: Fix garbled status messages in NOTATION_DATA" has nothing to do with the problem. So it can'r be the actual cause. Anway, I hope to get a 2.2.36 out this week.

iirc, we use ftruncate for ages now. The problem with the name ftruncate is that it looks to similar to the stdio functions. But sure, things should be flushed first.

The likely cause is that the secret key is not protected. Problem seems to be in gpg-agent.

Looking again at your report, I don't think it is an IPC problem (bad magic cooky was my assumption). I can replicate this with the current 2.2 but not with 2.3. Both un Unix.

Please don't play ping pong now,

Please report such bugs to RedHat - they use a modified Libgcrypt and thus it's there bug.

Sorry, there is no padding packet in OpenPGP. Please do no try to push ideas from that crypto-refresh-06 thing into GnuPG. We continue to follow the last draft with consesus, which is rfc4880bis-10.

The length limit of the signature sub packets are not reasy to pre-compute. Better to have a fatal error than a corrupt message. I am not sure whether we want to change this to a regualar error message - at that point we anyway need to stop.

You deleted the socket file but you did not restart the agent. Thus gpg can't contact the agent anymore. On Windows we use a socket emulation which requires the socket's file only for a new connection (to get the port and magic cookie).

Please provide a test case.

When I replied to the bug report I had the very same idea. Thanks for adding.

Here is a test signature with long notation data. During verification gpg faults when emitting the NOTATION_DATA lines.

ntbtls support only 1.2. We can't disable cipher suites for interop reasons. It is not the client's job trying to force a server 's admin to offer only decent ciphersuites.

Hmm, why not use:

gpgme_op_sign (ctx, in, out GPGME_SIG_MODE_CLEAR)

FWIW, on Unix is common to describe options as given on the standard shell.

You need to install the correct Let's Encrypt CA certificates on your legacy Windows box. Check the mailing lists for a discussion on this topic.

No crash here

Duplicate of T6021. Please don't create a new bug for one you already created (and which was marked as won'tfix).

The quotes are irrelevant because they are evaluated by the shell and don't make a difference here. A Unix shell is different than Windows cmd.exe.

Please provide a more verbose report.

Please explain what you mean by this. Which GnuPG version, which OS, which shell, what is the problem.

The --supervised option of GnuPG is deprecated and thus it does not make sense to add this to keyboxd or even sdaemon (which is a helper to gpg-agent).

A use case for this is to allow the use of S/MIME for de-vs mode and for standard mode while clearly indicating compliant certificates. As of now all certificates matching compliant algorithms are indicated as compliant. The new flag could be used to distinguish between them.

Thanks.

Can you do a search on the command line:

You may want to write gnupg-users@gnupg.org to tell about this tool. That seems to be a better place with a larger audience. Or you add it to wiki.gnupg.org.

Funnily I created a file dirmngr/rfc3161.c last Sunday. I can't tell how long it will take but I am definitely interested in using GnuPG to create qualified signatures. Timestamp support is at least good for testing.

Welche Gpg4win Version?
Welche Windows und Outlook Version?
Ist das die erste Installation oder ein Update?

At least old Windows versions did not add a nul in the truncation case. Thus I used to make that sure. I don't think we need it anymore.

Related problem exists with the modern ESIGN application. I think I fixed that but the whole Telesec eIDAS QES case needs more work.

Please let us turn this into a fatal error again. I had too many support cases where Kleo was actually run with Admin rights and messed up the permissions. To help with development issues and for the sake of some blockheads introduce an envvar to bypass the error.

For me it is faster:

ntbltls does not implement compression:

Please remember that GnuPG is a Unix tool. You might be interested in GPGME to write your own frontend.

As a Unix tool GnuPG does not touch its output. Diagnostic messages are only filtered for ASCII control characters because that is what command line tools should do. Everything else is up to your terminal emulation.

Thanks. The solution should thus be easy.

This specificiation is a draft which has not even been discussed in the WG. In any case gpg won't implement this because it would break processing of existing data.

Sorry, no. Use cat(1) for such translations.

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

AFAICS, we need to implement a new Assuan flag and wipe the data passed to the callback after the callback returned.

That is expected. The export re-encrypts the secret parts to comply with the OpenPGP specs and this includes a salt andf IV and thus the output must be different.