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.

cmd_keyinfo should be also updated to access the field correctly.

Also, it is better for a user, not to be asked confirmation (even if "Confirm:" is specified), that is, skipping the confirmation, when it is going to prompt the insertion of a card.

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.

Yes I agree to go for a.