On 15.05.18 17:53, Lukas Pitschl | GPGTools wrote:
>
>> Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig :
>>
>> I already tried a while ago to trick the Thunderbird HTML rendering
>> engine with tricks like this... They don't work. The rendering engine
>> ignores the tag (and also tags like ).
On 05/15/2018 04:44 AM, Patrick Brunschwig wrote:
> I think the correct solution must be to treat each MIME part
> independently, i.e. it needs to be parsed independently by the HTML
> engine and produce its own DOM tree. At the end, you can concatenate
> these DOM trees and create a single corr
I was testing the progress callback of GPGME in python and got some
strange results.
I'm using GPGME v1.11.1
$ cat progresstest.py
import gpg, tempfile
# Borrowed from callbacks.py
def progress_stdout(what, type, current, total, hook=None):
print("PROGRESS UPDATE: what = %s, type =
On 05/14/2018 02:02 AM, Andre Heinecke wrote:
> Hi,
>
> On Sunday, May 13, 2018 6:26:04 PM CEST Jacob Adams wrote:
>> As part of a program I'm writing this summer for GSoC, I'd like to be
>> able to both move gpg private keys to a smartcard and generate keys on
>> the smartcard from an application
> Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig :
>
> I already tried a while ago to trick the Thunderbird HTML rendering
> engine with tricks like this... They don't work. The rendering engine
> ignores the tag (and also tags like ).
>
> I think the correct solution must be to treat each M
On 15/05/18 16:44, Patrick Brunschwig wrote:
> I already tried a while ago to trick the Thunderbird HTML rendering
> engine with tricks like this... They don't work. The rendering engine
> ignores the tag (and also tags like ).
OK, that particular trick won't work. But if content injection is
pos
On Mon, May 14, 2018 at 04:48:31PM +0100, Mark Rousell wrote:
> Amongst other things this includes the following paragraph which, as I
> understand it, is essentially untrue:
>
> "There are currently no reliable fixes for the vulnerability. If you
> use PGP/GPG or S/MIME for very sensitive
On 15.05.18 16:59, Andrew Gallagher wrote:
> It struck me at lunch that it might be possible for gnupg itself to
> scupper the MIME concatenation (direct exfiltration) technique mentioned
> in efail, and thereby plug the leaks in multiple vulnerable clients at
> once. This would however require it
It struck me at lunch that it might be possible for gnupg itself to
scupper the MIME concatenation (direct exfiltration) technique mentioned
in efail, and thereby plug the leaks in multiple vulnerable clients at
once. This would however require it to be naughty with its output.
MIME concatenation
r...@sixdemonbag.org (Robert J. Hansen) writes:
>>> We hesitate to require the MDC also for old algorithms (3DES, CAST5>
>>> because a lot of data has been encrypted using them in the first
>>> years of OpenPGP.
>> So if someone sends me a 3DES-encrypted mail it won't check the MDC?
>> Doesn't gp
Just for information:
Am Dienstag 15 Mai 2018 08:52:45 schrieb Bernhard Reiter:
> .. to only display contents if there was integrity protection by either
[..]
I'll continue the discussion about what should technically be done
to gnupg on gnupg-devel@
> if users or frontends still want to show c
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
>
> > On 14 May 2018, at 18:32, Werner Koch wrote:
> >
> > On Mon, 14 May 2018 15:44, andr...@andrewg.com said:
> >
> >> This all exposes one of the difficulties with trying to manage security
> >> software in a decentralised
On 15/05/18 08:58, Werner Koch wrote:
>
> Unless you change the default options of gpg or you encrypt to at least
> one old key there is no problem at all. I assume that 99.9% of all GPG
> created messages are safe because they use MDC in away which allows the
> receiving GPG to hard fail if the M
Am Dienstag 15 Mai 2018 10:29:45 schrieb Andrew Gallagher:
> I’m not saying that active elements should be banned outright, just that
> they should be handled more carefully in the encrypted case than they are
> in plaintext.
> so we may want to suppress the handy “load images” button or have
> a
> Von: MFPA [mailto:2017-r3sgs86x8e-lists-gro...@riseup.net]
>
> Hi
>
> On Monday 14 May 2018 at 1:33:03 PM, in
> local>,
> Fiedler Roman wrote:-
>
> > This would also prevent many other programming
> > errors: e.g. if gpg
> > claims to have processed 2 signed messages, a client
> > has to verify,
On 14/05/18 14:44, Andrew Gallagher wrote:
> I would humbly suggest that we stop worrying about which side of the
> GPG/MUA fence the ball is on, and fix it on *both* sides.
I have just opened tickets in both GnuPG and Enigmail for the respective
integrity check mitigations.
https://dev.gnupg.org
On 14.05.18 19:32, Werner Koch wrote:
[...]
>> 1. change the default behaviour of GPG so that any integrity failure is
>> fatal by default, even for old ciphersuites (we could have a flag to
>
> I am all in favor of this and even considered to that some time ago.
> However, not too long ago we rem
On 15 May 2018, at 07:42, Bernhard Reiter wrote:
>> Another thing we need to learn from this is that HTML elements may be a
>> privacy concern in plaintext mail, but they are a *security* concern in
>> encrypted mail.
>
> People clearly seem to want a way to send files with potentially active
On Mon, 14 May 2018 22:43, andr...@andrewg.com said:
> If we believe that there will be more encrypted messages in the future than
> there have been in the past, then protecting those future messages takes
> priority, especially if an upgrade pathway exists.
Unless you change the default optio
Hi,
do you know any S/MIME (or CMS) implementations that
use authenticated-data type from STD 70 aka RFC 5652?
If we wanted to implement this for GnuPG's gpgsm,
it would be very cool to have implementations to test against.
The ticket is https://dev.gnupg.org/T3979, you can also reply there.
Tha
Am Montag 14 Mai 2018 22:43:56 schrieb Andrew Gallagher:
> > On 14 May 2018, at 18:32, Werner Koch wrote:
> > Well okay, with the new support of the Ehtmlfail paper we could now
> > point to that paper and always hard error out if no MDC is used even for
> > old algorithms. Shall we consider this
.. to only display contents if there was integrity protection by either
> a) MDC
> b) AEAD
> c) a signature over the whole contents from someone where it has been
> encrypted to (if this is feasable to detect).
if users or frontends still want to show contents, to me it seems good if
* th
22 matches
Mail list logo