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:

Or, it would be good for client side (in this case, gpg-agent) to specify the flag in the inquiry callback, that is, it's a kind of transient flag for a single transaction.

Revised version with new flag ASSUAN_CLEAR_INQUIRY_DATA.

Having written the code and the test I'm with dkg here. The code takes the expiration date, calculates the number of days from today and tells gpg to set the expiration to <number of days>d. The idea of the aforementioned is that it should work for any timezone. Maybe this assumption is wrong.

Subsequent downloads (also of the latest gnutls-3.7.5.tar.gz) where fast. Is there a configuration problem with loading uncached data, or was the bandwidth full at the first time?

Pushed rGea97683d5820: scd: Support automatic card selection for READCERT with keygrip..
I think that it works for PIV card.

For testing, I can use these sites for client certificate authentication:
https://stackoverflow.com/questions/38095559/https-test-server-that-checks-client-certificates

ntbltls does not implement compression:

Curious as to whether there's been any update on this. GPG4Win is the only approved whole email + attachment encryption solution on this end, and we're having trouble with inline images showing up as attachments only in Outlook 2016 (using GPG4Win 4.0.2). Of course, as you said, at least the attachment isn't being lost; however it does make reading rich emails more difficult.

Any progress on how the solution for this have been considered? Thanks.

I see the patch which does look like it will guarantee that the test suite succeeds. But does it solve the underlying problem, though? I worry that it might just paper over a more subtle problem.

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.

In T5975#158113, @werner wrote:

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

The second part is imho not a good idea. Libgcrypt is a building block for all kind of software and there are for sure legitimate reasons to use rsa512 (MCUs, short living keys, etc). Thus I think that the decision on the key size should be done by the software using libgcrypt.

I did some research about scree lockers (xtrlock, slock, swaylock, etc.).

Thanks. The solution should thus be easy.

The order to solve:

This is an experimental patch to support "Use-for-ssh":

I would be okay with GnuPG ignoring such packets, but I do not want verifying a signature or importing a key to activate the decompression code and its associated attack surface.

In T5993#158500, @werner wrote:

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.

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.