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 co
On Fri 2018-05-18 05:31:36 +, Fiedler Roman wrote:
> I see. If understood correctly, the trusted.gpg.d bypasses key
> management with apt-key completely, so not running into problems with
> apt-key deprecation.
I'm actually advocating avoiding trusted.gpg.d entirely as well, and
moving to expl
On Fri 2018-05-18 13:50:00 +, Whitey wrote:
> Robert J. Hansen wrote:
>> I don't have concrete numbers here, but my suspicion is that GnuPG is a
>> package verification system that's useful for email... and most of the
>> problems people have with it as a package verification system stem from
>
Robert J. Hansen wrote:
> I don't have concrete numbers here, but my suspicion is that GnuPG is a
> package verification system that's useful for email... and most of the
> problems people have with it as a package verification system stem from
> the fact it was originally an email privacy system.
Il 18/05/2018 07:31, Fiedler Roman ha scritto:
> I thought about that also, but shouldn't 99%+ of systems perform no pinning
> whatsoever of packages to repositories? In that case, the "wrong" repository
> could publish just a slightly increased package version number of a package
> from anothe
> Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net]
>
> On Thu 2018-05-17 15:37:55 +, Fiedler Roman wrote:
> > Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net]
> >
> >> See sources.list(5) and
> >> https://wiki.debian.org/DebianRepository/UseThirdParty for more details.
> >>
> >>
On 05/16/2018 08:59 PM, Werner Koch wrote:
> On Thu, 17 May 2018 01:39, miri...@riseup.net said:
>
>> However, I get that many users expect HTML, embedded images and links.
>
> Well they expect a bit of markup like *bold* or _underlined_ or
> /italics/ and links like https://gnupg.org but any dec
given that the OS package verification use case is relevant for
millions
of server installations, i'm not convinced that Linux on the Desktop is
really what rjh was referring to.
--dkg
dkg got it in one. Especially with the advent of cloud computing and
one-click deployments of whole
On Thu 2018-05-17 15:37:55 +, Fiedler Roman wrote:
> Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net]
>
>> See sources.list(5) and
>> https://wiki.debian.org/DebianRepository/UseThirdParty for more details.
>>
>> See also https://bugs.debian.org/877012 for suggestions about
>> improvem
On Thu 2018-05-17 10:01:37 +0200, Werner Koch wrote:
> On Thu, 17 May 2018 01:48, r...@sixdemonbag.org said:
>
>> While y'all are having this discussion, remember that GnuPG's 95% use
>> case is verifying Linux packages, and that number isn't expected to
>> change a whole lot.
>
> I am pretty sure
> Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net]
>
> On Thu 2018-05-17 08:45:18 +, Fiedler Roman wrote:
> > As gnupg starts getting more and more problematic regarding some
> > functions (see the discussions on command line/unattended use), Ubuntu
> > Bionic AND Debian Buster dropped
On Thu 2018-05-17 08:45:18 +, Fiedler Roman wrote:
> As gnupg starts getting more and more problematic regarding some
> functions (see the discussions on command line/unattended use), Ubuntu
> Bionic AND Debian Buster dropped it from their debootstrap
I don't know about Ubuntu Bionic, but for
-<| Quoting Andrew Gallagher , on Thursday, 2018-05-17
09:24:54 AM |>-
> On 17/05/18 09:11, Bernhard Reiter wrote:
> > I agree that technically HTML (with it extensions) is a bad format to serve
> > this need. Similiar to PDF. One RTF was an approach Nextstep's mail took
> > and that got some ado
On 17/05/18 00:39, Mirimir wrote:
> So the best solution would be a tweak to GnuPG that breaks HTML and
> embedded remote content.
I know I did suggest this earlier as a thought experiment, but MIME
issues are obviously better implemented in the mail client itself, or in
extremis in the secure mai
Mirimir wrote:
> So the best solution would be a tweak to GnuPG that breaks HTML and
> embedded remote content. That would protect against Efail, no matter how
> email clients were configured. It'd also protect against other exploits
> that depend on fetching remote content. And it wouldn't requir
On 05/17/2018 03:24 AM, Andrew Gallagher wrote:
> On 17/05/18 09:11, Bernhard Reiter wrote:
>> I agree that technically HTML (with it extensions) is a bad format to serve
>> this need. Similiar to PDF. One RTF was an approach Nextstep's mail took
>> and that got some adoption, but not enough. Toda
On 17/05/18 09:33, Werner Koch wrote:
> and remember that mail is serious work and not for amusement.
I think you're screaming into the wind there... ;-)
More seriously though, properly marked-up text is demonstrably easier to
read. That's why people submit academic papers in Latex instead of
cou
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
>
> Am Mittwoch 16 Mai 2018 15:46:05 schrieb Martin:
> > I think a fundamental discussion is necessary with the question: Who
> > should / will use GnuPG in the future?
>
> Note that during one contract in 2016 we came up with
On Thu, 17 May 2018 10:24, andr...@andrewg.com said:
> Content-type: text/markdown ;-)
Content-type: text/org-mode
But we need to disable Babel processing. So better stick with
Content-type: text/plain
and remember that mail is serious work and not for amusement.
Salam-Shalom,
Werner
-
On 16.05.18 21:50, Lukas Pitschl | GPGTools wrote:
>
>> Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig :
>>
>> Content-Type: mutlipart/mixed; boundary="WRAPPER"
>> Content-Description: Efail protection wrapper
>>
>> --WRAPPER
>> Content-Type: text/html
>>
>>
>>
>>
>>
>> --WRAPPER
>> (result
On 17/05/18 09:11, Bernhard Reiter wrote:
> I agree that technically HTML (with it extensions) is a bad format to serve
> this need. Similiar to PDF. One RTF was an approach Nextstep's mail took
> and that got some adoption, but not enough. Today it would be some very simple
> wiki markup language
On Thu, 17 May 2018 01:48, r...@sixdemonbag.org said:
> While y'all are having this discussion, remember that GnuPG's 95% use
> case is verifying Linux packages, and that number isn't expected to
> change a whole lot.
I am pretty sure that there are more Windows GPG users than users who
run Linux
Am Mittwoch 16 Mai 2018 15:46:05 schrieb Martin:
> I think a fundamental discussion is necessary with the question: Who
> should / will use GnuPG in the future?
Note that during one contract in 2016 we came up with some thoughts
in where GnuPG could be heading:
https://wiki.gnupg.org/EasyGpg2016/V
On Thu, 17 May 2018 01:39, miri...@riseup.net said:
> However, I get that many users expect HTML, embedded images and links.
Well they expect a bit of markup like *bold* or _underlined_ or
/italics/ and links like https://gnupg.org but any decent MUA already
supports this for plain text mails. P
> I think a fundamental discussion is necessary with the question: Who
> should / will use GnuPG in the future?
While y'all are having this discussion, remember that GnuPG's 95% use
case is verifying Linux packages, and that number isn't expected to
change a whole lot.
Email users are important,
On 05/16/2018 02:46 AM, Martin wrote:
> Hi
>
> Am Dienstag, 15. Mai 2018, 22:19:17 schreiben Sie:
>
>> 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 HT
> Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig :
>
> Content-Type: mutlipart/mixed; boundary="WRAPPER"
> Content-Description: Efail protection wrapper
>
> --WRAPPER
> Content-Type: text/html
>
>
>
>
>
> --WRAPPER
> (result of PGP/MIME decryption)
> —WRAPPER—
Looks alright so far, does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi
Am Dienstag, 15. Mai 2018, 22:19:17 schreiben Sie:
> 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
>>
On Tue, 15 May 2018 22:19, miri...@riseup.net said:
> So why use HTML with gnupg?
Even some of the journalist kicking that EFFective hype are using
encrypted mails with HTML content.
's/
pgpaY0DPHbkw1.pgp
Description: PGP signature
___
Gnupg-users mai
> On 16 May 2018, at 05:21, Patrick Brunschwig wrote:
>
> Content-Type: mutlipart/mixed; boundary="WRAPPER"
> Content-Description: Efail protection wrapper
>
> --WRAPPER
> Content-Type: text/html
>
>
>
>
>
> --WRAPPER
> (result of PGP/MIME decryption)
> --WRAPPER--
I like this. It handles
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
> 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 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
36 matches
Mail list logo
