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.

Lets implement it for 2.3

We meanwhile released two versions to our clients and are looking on how we can make it available to the community.

We have everything ready for a GnuPG Desktop Appimage but we first need a business case to maintain it.

We have a workaround by using a recent version of gpgtar directly. Thus lowering priority.

Please disable all other Add-Ins as well as extra security tools running on that machine to see whether there is some interference with them.

But only with an option - in general showing expired keys is annoying. For revoked keys the situation is different in case of a compromise - but many users revoke old keys anyway and we don't make use of the revocation reason. If we would consider the latter the UI/Support would be more complicated than useful.

Thanks for opening a ticket.

Thanks. Should be applied.

I can imagine thar there are use cases for this. Thus I see no problems for the first part.