--- tools.texi- Sat May 19 18:52:35 2018
+++ tools.texi Sat May 19 18:52:45 2018
@@ -290,7 +290,7 @@
Apply the configuration settings listed in @var{file} to the
configuration files. If @var{file} has no suffix and no slashes the
command first tries to read a file with the suffix @code{.prf}
--- gnupg.info-1- Sat May 19 19:01:41 2018
+++ gnupg.info-1Sat May 19 19:02:04 2018
@@ -2516,7 +2516,7 @@
below. A "!" indicates that the signature has been successfully
verified, a "-" denotes a bad signature and a "%" is used if an
error occurred while checking
(Also cross-posting to Autocrypt)
Patrick Brunschwig(patr...@enigmail.net)@Sat, May 19, 2018 at 06:47:08PM +0200:
> In the light of the Efail vulnerability I am asking myself if it's
> really needed to decrypt non-regular types of emails at all. In other
> words, should we decrypt a
Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig:
> I have actually thought through this during a sleepless night, and I
> believe that it could work as a quick and easy to implement *short term*
> measure until the mail clients have fixed the HTML rendering.
I do not think that HTML rendering
> I would consider the following "regular" MIME structures:
>
> 1. top-level MIME part is multipart/encrypted.
> 2. an attached email (Content-Type = message/rfc822) containing a
> multipart/encrypted MIME part as direct child.
We have been doing this in the past but changed it especially for
In the light of the Efail vulnerability I am asking myself if it's
really needed to decrypt non-regular types of emails at all. In other
words, should we decrypt a multipart/encrypted MIME part at all if we
detect an irregular MIME structure?
If we would not decrypt irregular MIME structures,
On 05/19/2018 09:00 AM, Patrick Brunschwig wrote:
> On 19.05.18 14:15, Werner Koch wrote:
>> On Fri, 18 May 2018 12:18, patr...@enigmail.net said:
>>
>>> How far back will that solution work? I.e. is this supported by all
>>> 2.0.x and 2.2.x versions of gpg?
>>
>> 2.0.19 (2012) was the first to
On 19.05.18 14:15, Werner Koch wrote:
> On Fri, 18 May 2018 12:18, patr...@enigmail.net said:
>
>> How far back will that solution work? I.e. is this supported by all
>> 2.0.x and 2.2.x versions of gpg?
>
> 2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case
> 2.0 is
On Fri, 18 May 2018 12:18, patr...@enigmail.net said:
> How far back will that solution work? I.e. is this supported by all
> 2.0.x and 2.2.x versions of gpg?
2.0.19 (2012) was the first to introduce DECRYPTION_INFO In any case
2.0 is end-of-life. In theory we could backport that to 1.4 but I
