Mailing List Archive

While having OpenPGP support directly in Thunderbird is probably a good
thing, I found it convenient to just use the gpg kerys for Email
encryption and signing (and conversely, being able to just use keys
imported via Enigmail to encrypt files using gpg).
It would be really nice, if Thunderbird could add an option to use the
gpg key storage instead of its own, but so far the developers want to
always keep the Thunderbird key storage separately (thoug they are
considering functionality to import keys from gpg to Thunderbird):

https://wiki.mozilla.org/Thunderbird:OpenPGP:2020

Philipp

Patrick Brunschwig wrote:

> The Thunderbird developers have announced that they will implement
> OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in
> Enigmail will therefore be discontinued.

[snip]

> The Thunderbird developers and I have therefore agreed that it's much
> better to implement OpenPGP support directly in Thunderbird. The set of
> functionalities will be different than what Enigmail offers, and at
> least initially likely be less feature-rich. But in my eyes, this is by
> far outweighed by the fact that OpenPGP will be part of Thunderbird and
> no add-on and no third-party tool will be required.

Great news, Patrick. Thanks for sharing!

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
certified OpenPGP key blocks available on keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Patrick Brunschwig <patrick@enigmail.net> wrote:
> The Thunderbird developers have announced that they will implement OpenPGP support in Thunderbird 78 [1].

A long awaited news indeed!

> Support for Thunderbird in Enigmail will therefore be discontinued.

Pity, but I hope it will be better that way. In particular I hope, that Mozilla will not follow your example and won’t entice users to proprietary isolated keyserver [0] instead of distributed SKS network thus splitting the keybase. And won’t promote standards [1] that suspiciously resemble embrace-extend-and-extinguish tactics employed against PGP either.

[0] https://keys.openpgp.org
[1] https://pep.security

Hi Patrick,

>The Thunderbird developers and I have therefore agreed that it's much
>better to implement OpenPGP support directly in Thunderbird. The set of
>functionalities will be different than what Enigmail offers, and at
>least initially likely be less feature-rich. But in my eyes, this is by
>far outweighed by the fact that OpenPGP will be part of Thunderbird and
>no add-on and no third-party tool will be required.

Great news overall and thanks for the announcement. Thunderbird with direct OpenPGP integration has long been overdue IMHO.

So according to the wiki page [1] I understand that the secret keys will be managed by Thunderbird. That is quite a limitation I think, in contrast to reusing a GPG agent of some sort. Depending on the chosen alternative, it might offer better OS integration, a long time proven secure process architecture, possible reuse with only one central key store and most of all integration with hardware tokens. I personally would not entrust my private keys to a mail application that also displays HTML and possibly executes JavaScript etc. after what we have seen with Efail for example.

So could you please elaborate or extend the wiki page to clear up how hardware tokens fit into the new picture?

Thanks and kind regards.
André

[1]: https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
--
Greetings...
From: Andre Colomb <acolomb@schickhardt.org>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> On 9 Oct 2019, at 04:47, Philipp Klaus Krause <pkk@spth.de> wrote:
>
> It would be really nice, if Thunderbird could add an option to use the
> gpg key storage instead of its own, but so far the developers want to
> always keep the Thunderbird key storage separately (thoug they are
> considering functionality to import keys from gpg to Thunderbird):

Agreed. Such functionality is vital for those of us who use smartcards.

A

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hello

I think it is an good Idea for such OSes as Windows or MAC that mainly depends on closed completely integrated Software.
But for Linux/Unix and alike it goes against the main principles of that Software.
And I think it will disturb the Development and Evolution of Software such as PeP, PGP, OpenPGP and so on what´s bad.

Am 2019-10-09 um 08:23 schrieb Andrew Gallagher:

On 9 Oct 2019, at 04:47, Philipp Klaus Krause <pkk@spth.de> wrote: It would be really nice, if Thunderbird could add an option to use the gpg key storage instead of its own, but so far the developers want to always keep the Thunderbird key storage separately (thoug they are considering functionality to import keys from gpg to Thunderbird):

Agreed. Such functionality is vital for those of us who use smartcards. A _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users"]http://lists.gnupg.org/mailman/listinfo/gnupg-users

I hope Mozilla will rethink that.
Thanks,
-- <pre> -========================== Jan-Peter Rühmann & Kuma =========================- Gubkower Str.7 [ Tel.: +49 38205 65484 ] jan-Peter@ruehmann.name 18195 Cammin / Prangendorf [ FAX: +49 38205 65212 ] https://www.ruehmann.name"]https://www.ruehmann.name WhatsApp: 491621316054 [ Tel.: +49 38205 65215 ] Twitter: @JPRuehmann [ Mobil: +49 162 1316054 ] IT-Servicetechniker -=============================================================================- Die Verwendung der Daten zu Werbezwecken ist verboten. </pre>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/8/19 9:34 AM, Philipp Klaus Krause wrote:
> It would be really nice, if Thunderbird could add an option to use the
> gpg key storage instead of its own, but so far the developers want to
> always keep the Thunderbird key storage separately (thoug they are
> considering functionality to import keys from gpg to Thunderbird):

It doesn't do that? Why would they choose to tightly couple TB with
OpenPGP? If I have to maintain two key databases, that's a dealbreaker for me.
Welp, looks like I won't be upgrading. Thanks Mozilla.
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXZ2G+QAKCRDo8fj9gx4T
04hBAgkBa3KJriiIvDBG91RKezHEYrPK10Y8Rcc4rYa4RSTq266MGgNu8R0lY8q9
dSYL6JgM+aRvfvD56bclhkTVl/mROJECBiIeo/CBtU78+RFq8hbgpb+4hI5GKt+R
s2/Oabhg+t5i9TZ4c3pG9y30A6Ih01bFgeX6FMA7HliGPGKr3PuWG0QO
=AwFo
-----END PGP SIGNATURE-----

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Philipp Klaus Krause writes:

> While having OpenPGP support directly in Thunderbird is probably a good
> thing, I found it convenient to just use the gpg kerys for Email
> encryption and signing (and conversely, being able to just use keys
> imported via Enigmail to encrypt files using gpg).
> It would be really nice, if Thunderbird could add an option to use the
> gpg key storage instead of its own, but so far the developers want to
> always keep the Thunderbird key storage separately (thoug they are
> considering functionality to import keys from gpg to Thunderbird):

Why the heck don't they just run gpg the way enigmail did?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Am 11.10.19 um 20:15 schrieb Phillip Susi:

> Why the heck don't they just run gpg the way enigmail did?
>

They don't want users to require to install gpg first. And they don't
want to ship gpg with Windows installers, since it isn't MPL.

Philipp

On 11/10/2019 19:15, Phillip Susi wrote:
> Why the heck don't they just run gpg the way enigmail did?

They don't want to bundle GnuPG because of GnuPG licence:

https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#OpenPGP_engine

Requiring user to set up GnuPG separately is out of question if
they want to achieve any sensible level of adoption.

There is another matter of key distribution and I guess they plan
on taking control over it to provide acceptable level of UX.

Cheers,
Chris

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

>
>> On 9 Oct 2019, at 04:47, Philipp Klaus Krause <pkk@spth.de> wrote:
>>
>> It would be really nice, if Thunderbird could add an option to use the
>> gpg key storage instead of its own, but so far the developers want to
>> always keep the Thunderbird key storage separately (thoug they are
>> considering functionality to import keys from gpg to Thunderbird):
>
> Agreed. Such functionality is vital for those of us who use smartcards.
>
> A
>

I would like to second this.

Storing private keys on a smartcard is a noteworthy security
enhancement, and I would like to see smartcard support being available
in Thunderbird. Either via GnuPG or some other mechanism.

Mis

> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 09/10/2019 08:06, Tony Lane via Gnupg-users wrote:> It doesn't do
that? Why would they choose to tightly couple TB with
> OpenPGP? If I have to maintain two key databases, that's a dealbreaker
for me.

Dealing with GnuPG complexity is a deal breaker for ordinary users,
preventing adoption. You need to look at it from product/business
development perspective and it makes perfect sense that they want to
ship their own UX.

Also, they mention that the key management workflow is something they
plan to address.

Cheers,
Chris

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Why the heck don't they just run gpg the way enigmail did?

Three major reasons:

1. License incompatibility. GnuPG is GPLv3, and Mozilla uses the
Mozilla Public License. They're not compatible. Arguably (and I
believe _correctly_) distributing GnuPG with Moz wouldn't be a
dealbreaker, as mere aggregation is different from actually linking, but
lawyers are by nature conservative. Moz has already said their lawyers
won't let them do this.

2. Dependencies. Mozilla will not accept responsibility for users
doing foolish things with their gpg.conf files, because those users will
expect Mozilla to fix it for them. It's a dealbreaker. This is also
why Mozilla has declared they won't even support using GnuPG keyrings --
they're going to insist on running their own keyring internal to
Thunderbird which isn't shared with anything else. (I imagine
*importing* from a GnuPG keyring will be supported, but *sharing* a
keyring is right out.)

3. Enigmail has shown them the limitations of GnuPG. The Efail attack
on Enigmail was very real. It was created by an ambiguity in how GnuPG
returns error states: just because GnuPG says "decryption OK" doesn't
mean it was decrypted okay. (Whether Enigmail should've understood
this, or whether GnuPG should have not returned such an ambiguous
message, is an open question and not one I'm interested in discussing.)
Rather than repeat Enigmail's interface, which historically had its
fair share of security problems, Mozilla has decided to go a different
route.

More power to 'em. I love Enigmail, but it's the nature of all software
that at some point we learn how to do things better. When we learn how
to do things better, we should elect to do them better rather than stay
mired in the past.

(... and that principle, applied to OpenPGP, suggests throwing out a
whole lot of cruft. Which is another open question I'm not interested
in discussing, except to throw it out there for people to think about.)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Which ccomplexity?

Creating the Key is the only thing that the normal User has to do, That is possible via a Menue Entry.
I don´t see the Problem.

Am 2019-10-11 um 21:49 schrieb Chris Narkiewicz via Gnupg-users:

On 09/10/2019 08:06, Tony Lane via Gnupg-users wrote:> It doesn't do that? Why would they choose to tightly couple TB with

OpenPGP? If I have to maintain two key databases, that's a dealbreaker

for me. Dealing with GnuPG complexity is a deal breaker for ordinary users, preventing adoption. You need to look at it from product/business development perspective and it makes perfect sense that they want to ship their own UX. Also, they mention that the key management workflow is something they plan to address. Cheers, Chris _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users"]http://lists.gnupg.org/mailman/listinfo/gnupg-users

Thanks,
-- <pre> -========================== Jan-Peter Rühmann & Kuma =========================- Gubkower Str.7 [ Tel.: +49 38205 65484 ] jan-Peter@ruehmann.name 18195 Cammin / Prangendorf [ FAX: +49 38205 65212 ] https://www.ruehmann.name"]https://www.ruehmann.name WhatsApp: 491621316054 [ Tel.: +49 38205 65215 ] Twitter: @JPRuehmann [ Mobil: +49 162 1316054 ] IT-Servicetechniker -=============================================================================- Die Verwendung der Daten zu Werbezwecken ist verboten. </pre>

Philipp Klaus Krause [2019-10-08T15:34:28+02] wrote:

> It would be really nice, if Thunderbird could add an option to use the
> gpg key storage instead of its own, [...]

I agree with that even though I have never really used Thunderbird.

But using a custom key storage and implementation (or do they use
Sequoia PGP library?) is an interesting choice in the world of Unix-like
systems. It's pretty much the normal way elsewhere, though.

PGP and GnuPG and the related communities have tried really hard to
build a system based on person's long-term identity keys. All that web
of trust thing relies on keys that are used relatively long time. But as
we know this doesn't work for most people. People are really bad at
maintaining long-term identity keys. I think this is the most important
reason why other software just auto-generate "device keys" or
"application keys" and exchange them. They just forget about the
identity part and keys' usage in the long term. Change your phone or
just reinstall the application and you'll have new keys. Keys come and
go and it's perfectly normal.

Thunderbird seems to be going to that direction and it is probably a
good thing. From the mindset of crypto nerds (like us) or Unixy tool box
this can be a barrier, obviously.

--
/// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
// https://keys.openpgp.org/search?q=tlikonen@iki.fi
/ https://keybase.io/tlikonen https://github.com/tlikonen

Hej all,

Am 12.10.19 um 08:23 schrieb Robert J. Hansen:
> they're going to insist on running their own keyring internal to
> Thunderbird which isn't shared with anything else. (I imagine
> *importing* from a GnuPG keyring will be supported, but *sharing* a
> keyring is right out.)

_They_ can insist on whatever they want. If they close their shop
towards external built keys (for example with xca), they hopefully won't
find much acceptance.....

regards,

B.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> PGP and GnuPG and the related communities have tried really hard to
> build a system based on person's long-term identity keys. All that web
> of trust thing relies on keys that are used relatively long time. But as
> we know this doesn't work for most people. People are really bad at
> maintaining long-term identity keys.

A few years ago at Circumvention (the first Internet Freedom Festival),
I was asked to give an impromptu talk on Things You're Doing Wrong With
OpenPGP.

The first thing on my list was certificate lifetime. We teach people
the importance of maintaining their certificate for the long haul, but
we also know very few people are capable of doing that. What we *don't*
teach them is how to rebuild their trust network after a
loss-of-certificate event. So when someone loses their cert, or has a
system compromise, or their YubiKey goes through the laundry, or
what-have-you, they get a double whammy of failure: they feel like a
failure because they didn't do this thing that was expected of them
(keep the cert for 20+ years, never mind how unreasonable that it), and
they feel like a failure for not knowing how to recover from it.

So instead: teach people that it's okay to lose a cert, so long as you
have a plan to come back from it. Then if their Yubi goes through the
laundry they (a) don't feel like a failure and (b) already have a plan
for how to move forward.

Seriously, ending the Cult of the Long-Term Certificate is one of the
simple but good things I think we should be embracing for the sake of users.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Fri, 11 Oct 2019 20:18, Philipp Klaus Krause said:

> They don't want users to require to install gpg first. And they don't
> want to ship gpg with Windows installers, since it isn't MPL.

The latter is just plain bullshit. There are even many proprietary
products which bundle gpg or other GPL code with their proprietary or
MPL licensed code. Not just small companies but large ones with huge
and conservative legal departments. The actual requirements for
distribution are easy to fulfill and are actually easier with the GPLv3
than with the v2.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Sat, 12 Oct 2019 02:23, Robert J. Hansen said:

> on Enigmail was very real. It was created by an ambiguity in how GnuPG
> returns error states: just because GnuPG says "decryption OK" doesn't

Nope. They did not read the documentation and did not checked error
codes. We suggest for a reason to use GPGME to make error checking
easy. You can't just code things down along some specs without thinking
over the implications.

Still, TB is still subject to those attacks because their primary
encryption protocol is S/MIME and the last time I checked S/MIME (well,
CMS for the nitpickers) does not supoport any kind of authenticated
encryption. In contarst OpenPGP provides this nearly for 2 decades.
Mozilla has not even stepped forward and implemented one of the
meanwhile old proposal to move to AE. So Microsoft had to take the lead
to do this (rumors are that the next OL version will allow for GCM mode)

After 20 years of strong resistance against implementing OpenPGP [1], they
finally seem to do it. That is a good move.


Shalom-Salam,

Werner


[1] Back in ~1999, when Mozilla rewrote the entire mail engine, I
implemented a first version of PGP/MIME code which was rejected due to
their policy of only supporting S/MIME. For a term paper a German
student later took up on my code, extended and cleaned it up. Again it
was rejected. About 2005 we had a meeting with them to propose that we
implement S/MIME again in a way that would comply to the strong policy
requirements here in Germany and also to implement OpenPGP as an
additional protocol. It was again rejected.

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Fri, 11 Oct 2019 21:48, qwrd said:

> Storing private keys on a smartcard is a noteworthy security
> enhancement, and I would like to see smartcard support being available
> in Thunderbird. Either via GnuPG or some other mechanism.

Take a Yubikey or an OpenPGP smartcard, install Scute (pcks#11
provider) and GnuPG and you are done. Either S/MIME or OpenPGP.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On 12/10/2019 12:14, Werner Koch via Gnupg-users wrote:
> After 20 years of strong resistance against implementing OpenPGP [1], they
> finally seem to do it. That is a good move.

Do you know why they resited OpenPGP adoption it so much?

Cheers,
Chris

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sat, Oct 12, 2019 at 10:13:59AM +0300, Teemu Likonen via Gnupg-users wrote:
> Philipp Klaus Krause [2019-10-08T15:34:28+02] wrote:
>
> > It would be really nice, if Thunderbird could add an option to use the
> > gpg key storage instead of its own, [...]
>
> I agree with that even though I have never really used Thunderbird.
>
> But using a custom key storage and implementation (or do they use
> Sequoia PGP library?) is an interesting choice in the world of Unix-like
> systems. It's pretty much the normal way elsewhere, though.
>
> PGP and GnuPG and the related communities have tried really hard to
> build a system based on person's long-term identity keys. All that web
> of trust thing relies on keys that are used relatively long time. But as
> we know this doesn't work for most people. People are really bad at
> maintaining long-term identity keys. I think this is the most important
> reason why other software just auto-generate "device keys" or
> "application keys" and exchange them. They just forget about the
> identity part and keys' usage in the long term. Change your phone or
> just reinstall the application and you'll have new keys. Keys come and
> go and it's perfectly normal.

That would be one of the reasons why I tend to avoid "other software".
My primary use-case is identity, not secrecy. I am not alone: quite a
few employers are at last discovering crypto signatures in their
efforts to combat spear-phishing, and spending quite a bit of money
and effort to deploy them. (I accept that most of them are using
S/MIME rather than OpenPGP, but that's a detail; identity is important.)

> Thunderbird seems to be going to that direction and it is probably a
> good thing. From the mindset of crypto nerds (like us) or Unixy tool box
> this can be a barrier, obviously.

Humph, I was already grumpy about Mozilla products' insistence on
having their own insular X.509 store, meaning that I have to install
certificates twice (once for Firefox, again for *everything else*.)

Maybe there will be an add-on, so that those who care can choose to
integrate Thunderbird into their systems rather than having it still
standing off to one side haughtily awaiting special treatment.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

On Sat, Oct 12, 2019 at 08:07:58AM -0400, Mark H. Wood wrote:
>Humph, I was already grumpy about Mozilla products' insistence on
>having their own insular X.509 store, meaning that I have to install
>certificates twice (once for Firefox, again for *everything else*.)

Slightly off-topic for this list, but on unix-like systems, you can
force Firefox to use the system store of X.509 certificates (in
/etc/ssl/certs) by replacing Firefox’s libnssckbi.so library by the
libp11-kit.so library from the p11-kit project [1,2].

This also works with Thunderbird and with LibreOffice.

- Damien


[1] https://p11-glue.github.io/p11-glue/p11-kit.html
[2]
https://askubuntu.com/questions/244582/add-certificate-authorities-system-wide-on-firefox/1036637#1036637

BruderB wrote on 12.10.2019 10:43:
> Hej all,
>
> Am 12.10.19 um 08:23 schrieb Robert J. Hansen:
>> they're going to insist on running their own keyring internal to
>> Thunderbird which isn't shared with anything else. (I imagine
>> *importing* from a GnuPG keyring will be supported, but *sharing* a
>> keyring is right out.)
>
> _They_ can insist on whatever they want. If they close their shop
> towards external built keys (for example with xca), they hopefully won't
> find much acceptance.....

The vast majority of users of Enigmail (somewhere around 98%) don't use
external built keys. The vast majority of users also don't use GnuPG for
anything else than email. These users don't care where their key is
stored, nor which software under the hood is used for the crypto. All
they care is that encryption works smoothly.

I'm sorry, but everything written here is pure speculation. We are still
in the phase of considering our options. Depending on the chosen
approach, we may just as well end up with something completely different
than what you'd imagine.

The most important aspects from our side are the following: The chosen
solution must run smoothly for the ~20M users of Thunderbird without
causing a large amount of support/setup issues. We want to have
something that satisfies as many users of Enigmail as possible. We
certainly don't want to have people run away from Thunderbird because of
OpenPGP.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

By the Way, this goes for the vast Majority of People that drives, heats aso. by Oil and Gas as well.

Am 2019-10-13 um 08:21 schrieb Patrick Brunschwig:

BruderB wrote on 12.10.2019 10:43:

Hej all, Am 12.10.19 um 08:23 schrieb Robert J. Hansen:

they're going to insist on running their own keyring internal to Thunderbird which isn't shared with anything else. (I imagine *importing* from a GnuPG keyring will be supported, but *sharing* a keyring is right out.)

_They_ can insist on whatever they want. If they close their shop towards external built keys (for example with xca), they hopefully won't find much acceptance.....

The vast majority of users of Enigmail (somewhere around 98%) don't use external built keys. The vast majority of users also don't use GnuPG for anything else than email. These users don't care where their key is stored, nor which software under the hood is used for the crypto. All they care is that encryption works smoothly. I'm sorry, but everything written here is pure speculation. We are still in the phase of considering our options. Depending on the chosen approach, we may just as well end up with something completely different than what you'd imagine. The most important aspects from our side are the following: The chosen solution must run smoothly for the ~20M users of Thunderbird without causing a large amount of support/setup issues. We want to have something that satisfies as many users of Enigmail as possible. We certainly don't want to have people run away from Thunderbird because of OpenPGP. -Patrick _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users"]http://lists.gnupg.org/mailman/listinfo/gnupg-users

-- <pre> -========================== Jan-Peter Rühmann & Kuma =========================- Gubkower Str.7 [ Tel.: +49 38205 65484 ] jan-Peter@ruehmann.name 18195 Cammin / Prangendorf [ FAX: +49 38205 65212 ] https://www.ruehmann.name"]https://www.ruehmann.name WhatsApp: 491621316054 [ Tel.: +49 38205 65215 ] Twitter: @JPRuehmann [ Mobil: +49 162 1316054 ] IT-Servicetechniker -=============================================================================- Die Verwendung der Daten zu Werbezwecken ist verboten. </pre>

On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said:

> Do you know why they resited OpenPGP adoption it so much?

iirc, they said that they want to support only one protocol and settled
for S/MIME. This still did not explain why they rejected our proposal
to clean up their S/MIME code and implement missing stuff so that TB
could be used for tasks of the German administrative and to be
compatible with a wider range of S/MIME implementations. The plan was
to do that all within TB and without external dependencies.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Werner Koch via Gnupg-users wrote on 13.10.2019 11:56:
> On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said:
>
>> Do you know why they resited OpenPGP adoption it so much?
>
> iirc, they said that they want to support only one protocol and settled
> for S/MIME. This still did not explain why they rejected our proposal
> to clean up their S/MIME code and implement missing stuff so that TB
> could be used for tasks of the German administrative and to be
> compatible with a wider range of S/MIME implementations. The plan was
> to do that all within TB and without external dependencies.

I think there are two reasons why TB changed their minds:
1. there are different people working on Thunderbird than years ago.
2. in the past, TB was a direct part of Mozilla. Now, Thunderbird is an
independent organization under the umbrella of the Mozilla Foundation,
with an independent council and their own independent financial income
stream.

These two factors lead to a completely different mindset towards what is
good for TB.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 08.10.2019 09:08, Patrick Brunschwig wrote:
> The Thunderbird developers have announced that they will implement
> OpenPGP support in Thunderbird 78 [1]. Support for Thunderbird in
> Enigmail will therefore be discontinued.
>
> [Snip]
>
> I will continue to support and maintain Enigmail for Thunderbird 68
> until 6 months after Thunderbird 78 will have been released (i.e. a few
> months beyond Thunderbird 68 EOL). Enigmail will not run anymore on
> Thunderbird 72 beta and newer.

IMHO, integrating PGP into TB in general is a good decision. However, I
have two concerns (being a naive user, and being far away from
understanding the technical aspects).

1) The schedule

We have all been educated to update our applications (notably, "internet
applications" like browser and email clients) as soon as updates are
available; at least, this is true for security updates.

Despite release plans, I think nobody knows for sure how much time
actually will pass between TB 72's predecessor and TB 78, and how many
security updates will be released between these versions.

During that time, I either can't use Enigmail (if I decide to install
the security updates), or I have to ignore the security updates
(possibly putting me to risk).

Did I understand this correctly?

I am not on a level that I would use GnuPG on the command line to
encrypt or authenticate my messages (encryption is fascinating, and if I
had the time, it would be a pleasure to dive deeply into this subject,
but for the time being, I just need it working), so I am dependent on
the TB / Enigmail duo (at least until TB 78).

2) The features

When integrating PGP into TB, IMHO great attention must be paid that
none of the important features of Enigmail / GnuPG get lost, not even in
the first version. The statement that the first implementation probably
will be "less feature-rich" than Enigmail (let alone GnuPG) really
frightens me and lets me expect all sorts of problems.

For example, even I (as a non-advanced user) recently had an issue where
I could not use PGP keys which were generated by Enigmail, because the
keys' IDs were formally wrong so that key servers didn't accept the
keys. The easiest possible solution was to re-generate these keys using
GnuPG on the command line (despite my statement above ...) and import
them into Enigmail.

This simple case shows that we actually need the full functionality of a
mature software package like GnuPG from the beginning on (note that my
problem was ridiculously simple, but even then I couldn't easily solve
it using Enigmail alone).

My feeling is that TB (and probably email encryption / authentication
per se) will lose a lot of users (including me) if the first
implementation lacks essential features, makes the encryption setup fail
due to common problems (like mine), or makes encryption unusable or
difficult in any other way.

By the way, being able to encrypt the subject of an encrypted message
also is one of the essential features (thanks, Patrick, and thanks,
Werner, that you finally have made this possible a while ago!) ...

Just my 2 cents ...

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sun, 13 Oct 2019 18:27, Binarus said:

> keys' IDs were formally wrong so that key servers didn't accept the
> keys. The easiest possible solution was to re-generate these keys using

For the records: Not /keyservers/ but one specific keyserver which runs
on a not yet matured enough code base and is thus expected to have bugs.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On 13.10.2019 18:51, Werner Koch wrote:
> On Sun, 13 Oct 2019 18:27, Binarus said:
>
>> keys' IDs were formally wrong so that key servers didn't accept the
>> keys. The easiest possible solution was to re-generate these keys using
>
> For the records: Not /keyservers/ but one specific keyserver which runs
> on a not yet matured enough code base and is thus expected to have bugs.
>

Thank you very much for your remark.

Actually, I have meant this to be just an example for the problems to
expect if too many features are missing.

Secondly, I suspect that there are more keyservers out there (running
other software) which also would reject those keys (I didn't try,
though, so this is speculation).

Thirdly, this is the keyserver which is preset in Enigmail (I didn't
change the default). For naive users like me, it is not possible to
check a keyserver's software version and to analyze how mature / stable
it is. I even wouldn't come to that idea, because this is the default
keyserver in a well-known software package :-) If I wouldn't have been
able to generate correct keys / IDs using GnuPG directly, I eventually
would have given up on encryption.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 10/13/19 2:21 AM, Patrick Brunschwig wrote:
> The vast majority of users of Enigmail (somewhere around 98%) don't use
> external built keys.

How do you know this?

> The vast majority of users also don't use GnuPG for
> anything else than email. These users don't care where their key is
> stored, nor which software under the hood is used for the crypto. All
> they care is that encryption works smoothly.

And this?

> The most important aspects from our side are the following: The chosen
> solution must run smoothly for the ~20M users of Thunderbird without
> causing a large amount of support/setup issues.

Presumably those ~20,000,000 will have to opt-in to use Thunderbird
encryption. Most won't for the same reason they don't install and use
Enigmail now. They don't particularly care about privacy, and the few
who do care correspond with people who don't.

> We want to have
> something that satisfies as many users of Enigmail as possible. We
> certainly don't want to have people run away from Thunderbird because of
> OpenPGP.

If responses to my posts in the "We have GOT TO make things simpler"
thread are any indication, you'll be looking at quite a few back sides.
Is there any reason to think that folks who object to easy-to-use
proprietary encrypted email solutions from ProtonMail and Tutanota will
embrace a proprietary encrypted email solution from Thunderbird?

Jeff Allen

Binarus wrote on 13.10.2019 18:27:
[...]
> 1) The schedule
>
> We have all been educated to update our applications (notably, "internet
> applications" like browser and email clients) as soon as updates are
> available; at least, this is true for security updates.
>
> Despite release plans, I think nobody knows for sure how much time
> actually will pass between TB 72's predecessor and TB 78, and how many
> security updates will be released between these versions.
>
> During that time, I either can't use Enigmail (if I decide to install
> the security updates), or I have to ignore the security updates
> (possibly putting me to risk).
>
> Did I understand this correctly?

The current stable version of Thunderbird is 68 (and 60 for a few more
weeks); the next stable version will be 78. Users of Enigmail staying on
the stable version of Thunderbird will receive all security updates
until TB 78 will be available. Thunderbird 69 ... 77 are only released
as beta versions that are not intended for end users.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote:
> On 10/13/19 2:21 AM, Patrick Brunschwig wrote:
>> The vast majority of users of Enigmail (somewhere around 98%) don't use
>> external built keys.
>
> How do you know this?
>

I don't know either, but perhaps it is in the debug logs the Enigmail
team analyzes?

>> The vast majority of users also don't use GnuPG for
>> anything else than email. These users don't care where their key is
>> stored, nor which software under the hood is used for the crypto. All
>> they care is that encryption works smoothly.
>
> And this?
>

I am also not sure about this. As far as it concerns Windows, the first
part of the statement may be true. There is plenty of software to
encrypt single files or directories for Windows, including the software
which is part of the O/S. People probably tend to go the easiest way,
even if another solution would be safer and technically superior. I
don't know the situation under Linux well enough to comment.

I disagree with the second part of the statement, though. Most of the
people who think about privacy and email encryption / authentication at
all are educated, non-average users who want to be sure that there are
no backdoors in their software and that they use it as safely as
possible (meaning that they care about software, algorithms and
ciphers), and who want to backup their keys (meaning that they care
where the keys are stored). And yes, I want to decide on my own if my
key is ED25519, RSA1024 or RSA4096 :-)

>> The most important aspects from our side are the following: The chosen
>> solution must run smoothly for the ~20M users of Thunderbird without
>> causing a large amount of support/setup issues.
>
> Presumably those ~20,000,000 will have to opt-in to use Thunderbird
> encryption. Most won't for the same reason they don't install and use
> Enigmail now. They don't particularly care about privacy, and the few
> who do care correspond with people who don't.
>

I am not sure where this will lead to. It sounds as if you were
suggesting to give up on privacy, encryption and authentication for that
reason.

While I agree with you that this problem exists and is quite difficult
to solve (eventually it needs another decade), I am absolutely sure that
bad and difficult software will make it worse, but good and usable
software will help in solving it. The fact that the problem exists does
not mean that nobody should try to solve it by providing easier-to-use,
fully integrated software with reasonable default settings.

>> We want to have
>> something that satisfies as many users of Enigmail as possible. We
>> certainly don't want to have people run away from Thunderbird because of
>> OpenPGP.
>
> [Snip]
>
> Is there any reason to think that folks who object to easy-to-use
> proprietary encrypted email solutions from ProtonMail and Tutanota will
> embrace a proprietary encrypted email solution from Thunderbird?
>

There are many reasons to think so (the following applies to ProtonMail
as well as Tutanota):

1) To actually use those services in a reasonable manner, you have to
opt-in for a paid contract. For most of us, this is a matter of
principle. Why should we pay for a thing that used to be free all the
time? (Note: I don't want to judge that attitude - I am just stating how
it is).

2) None of that services supports IMAP or POP3. I would be totally crazy
if I would make myself totally dependent on companies or services which
won't let me download my messages and integrate them into my email client.

What happens if those companies suddenly stop their service and you
haven't downloaded your messages yet (which anyway seems to be
impossible)? Or if you decide that you want to use another service? How
long will you be able to access your messages after you have stopped
paying your old service? Will they delete your messages until the quota
for free usage is reached again?

I insist on having all important data, including email messages,
in-house and under my complete control, and I strongly advise each of my
customers to do the same. So far, all of them are following that advice.
Therefore, such services never will have any chance to do business with
my customers.

3) I have several email addresses. I am definitely not ready to use a
different website or different software for each of them. That is, there
is absolutely no chance that I ever will use a service which does not
provide POP3 or IMAP (or, for the protocol, their successors).

I want *one* MUA (like Thunderbird) to be able to manage *all* of my
email messages in *one* place (For example, ever needed to search for a
message for which you can't remember the account it was received on? -
The global search in TB is very handy here. Further reasons: junk
filtering, action filters (automatically moving certain messages in
subfolders) and so on, all managed at one place, public folders, shared
folders and so on).

4) I doubt that these services can be legally used by businesses in
Germany. We are having some weird rules here, one of them saying that we
have to keep *each* (electronic) message we are receiving and sending in
a separate archive where users don't have access to. That is, users of
course may do anything they want in their normal email account, but all
messages which are ever sent or received must first be copied somewhere
where they cannot be manipulated or deleted.

I can't imagine how this could be achieved when using those services.

These are only a few of the many reasons against using a purely
cloud-based email system.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 14.10.2019 09:17, Patrick Brunschwig wrote:
> Binarus wrote on 13.10.2019 18:27:
> [...]
>> 1) The schedule
>>
>> We have all been educated to update our applications (notably, "internet
>> applications" like browser and email clients) as soon as updates are
>> available; at least, this is true for security updates.
>>
>> Despite release plans, I think nobody knows for sure how much time
>> actually will pass between TB 72's predecessor and TB 78, and how many
>> security updates will be released between these versions.
>>
>> During that time, I either can't use Enigmail (if I decide to install
>> the security updates), or I have to ignore the security updates
>> (possibly putting me to risk).
>>
>> Did I understand this correctly?
>
> The current stable version of Thunderbird is 68 (and 60 for a few more
> weeks); the next stable version will be 78. Users of Enigmail staying on
> the stable version of Thunderbird will receive all security updates
> until TB 78 will be available. Thunderbird 69 ... 77 are only released
> as beta versions that are not intended for end users.
>

I see. Thank you very much for the clarification. This relieves a lot of
tension.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 10/14/19 3:40 AM, Binarus wrote:
>
> On 13.10.2019 22:27, Jeff Allen via Gnupg-users wrote:
>> On 10/13/19 2:21 AM, Patrick Brunschwig wrote:
>>> The vast majority of users of Enigmail (somewhere around 98%) don't use
>>> external built keys.
>>
>> How do you know this?
>>
>
> I don't know either, but perhaps it is in the debug logs the Enigmail
> team analyzes?

I have used Enigmail since its inception and have never knowingly
submitted a log or answered a survey and have always assumed Enigmail
does not phone home.

>>> The vast majority of users also don't use GnuPG for
>>> anything else than email. These users don't care where their key is
>>> stored, nor which software under the hood is used for the crypto. All
>>> they care is that encryption works smoothly.
>>
>> And this?
>>
>
> I am also not sure about this. As far as it concerns Windows, the first
> part of the statement may be true.

All the statements might be true. My question was "How do you know?"

<snip>

> I disagree with the second part of the statement, though. Most of the
> people who think about privacy and email encryption / authentication at
> all are educated, non-average users who want to be sure that there are
> no backdoors in their software and that they use it as safely as
> possible (meaning that they care about software, algorithms and
> ciphers), and who want to backup their keys (meaning that they care
> where the keys are stored). And yes, I want to decide on my own if my
> key is ED25519, RSA1024 or RSA4096 :-)

I agree and think Patrick underestimates the number of GnuPG/Enigmail
users who care a lot about the details. My argument in the other thread
was that folks who value privacy and encryption but can't be burdened by
the details have reasonably secure easy-to-use options available.
Enigmail is, of course, one of them.

>>> The most important aspects from our side are the following: The chosen
>>> solution must run smoothly for the ~20M users of Thunderbird without
>>> causing a large amount of support/setup issues.
>>
>> Presumably those ~20,000,000 will have to opt-in to use Thunderbird
>> encryption. Most won't for the same reason they don't install and use
>> Enigmail now. They don't particularly care about privacy, and the few
>> who do care correspond with people who don't.
>>
>
> I am not sure where this will lead to. It sounds as if you were
> suggesting to give up on privacy, encryption and authentication for that
> reason.

Not at all. My point was that I doubt OpenPGP's inclusion in
Thunderbird will have a major impact on the number of people encrypting
their email.

> While I agree with you that this problem exists and is quite difficult
> to solve (eventually it needs another decade), I am absolutely sure that
> bad and difficult software will make it worse, but good and usable
> software will help in solving it. The fact that the problem exists does
> not mean that nobody should try to solve it by providing easier-to-use,
> fully integrated software with reasonable default settings.

Here we disagree. I believe that existing software is not that
difficult to use. The problem, if there is one, is that most people
simply aren't interested. Twenty years ago I thought that everyone
would soon be using end-to-end encrypted email. Twenty years from now
they still won't be.

>>> We want to have
>>> something that satisfies as many users of Enigmail as possible. We
>>> certainly don't want to have people run away from Thunderbird because of
>>> OpenPGP.
>>
>> [Snip]
>>
>> Is there any reason to think that folks who object to easy-to-use
>> proprietary encrypted email solutions from ProtonMail and Tutanota will
>> embrace a proprietary encrypted email solution from Thunderbird?
>>
>
> There are many reasons to think so (the following applies to ProtonMail
> as well as Tutanota):
>
> 1) To actually use those services in a reasonable manner, you have to
> opt-in for a paid contract. For most of us, this is a matter of
> principle. Why should we pay for a thing that used to be free all the
> time? (Note: I don't want to judge that attitude - I am just stating how
> it is).

<snip>

But "free" email has never been free from the likes of Gmail, Yahoo,
GMX, etc. While you don't pay a yearly fee, you trade your privacy for
a few bucks. You open yourself to tracking and targeted advertising.
Your email is anything but private. A couple years back both Google and
Yahoo claimed to be working on E2EE. I wonder why it never happened?

The free versions of ProtonMail, Tutanota and Mailfence at least
preserve your privacy. They aren't monetized through advertising and
tracking. Instead they sell premium services to people who want more
capacity or features. Many people I know do email exclusively on their
smart phones. They don't use an MUA and don't care about POP3, IMAP or
SMTP. Their view of using email services in a reasonable manner doesn't
comport with yours or mine.

<snip>

I hope I am wrong and Thunderbird's OpenPGP implementation is a complete
success encouraging many more people to encrypt their email. I would,
however, personally prefer that Thunderbird directly implement GnuPG
integration instead of going it alone. That would satisfy both casual
and power users as Enigmail does now.

Will Thunderbird OpenPGP support smart cards like my Yubikey? How about
a feature like GnuPG's group line or Enigmail's per-recipient rules?
In-line PGP as well as PGP/MIME? Encrypted subject and the ability to
turn it on or off? As far as I know, they are all features of GnuPG or
Enigmail and not required by the OpenPGP specification.

Patrick and company deserve our thanks for many years splendid service
to the OpenPGP community. So does Werner and his team who created and
maintain a tool that has satisfied a wide range of users for decades. I
doubt that yet another proprietary OpenPGP system is what the world needs.

Jeff Allen

Werner Koch via Gnupg-users writes:

> Still, TB is still subject to those attacks because their primary
> encryption protocol is S/MIME and the last time I checked S/MIME (well,
> CMS for the nitpickers) does not supoport any kind of authenticated
> encryption. In contarst OpenPGP provides this nearly for 2 decades.

What do you mean? S/MIME authenticates the user's identity via the CA.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, 14 Oct 2019 10:54, Phillip Susi said:

>> encryption protocol is S/MIME and the last time I checked S/MIME (well,
>> CMS for the nitpickers) does not supoport any kind of authenticated
>> encryption. In contarst OpenPGP provides this nearly for 2 decades.
>
> What do you mean? S/MIME authenticates the user's identity via the CA.

authenticated encryption is different from signed and encrypted mails.
There are relative easy attacks on the encryption layer if standard
encryption modes like CBC (as in S/MIME) are used. Whether this really
affects users is a different question but they can be used to leverage
implementation flaws in MUAs to full plaintext leaks. This is known for
20 years and made it last year again to the media under the term EFAIL.

Granted, encrypted+signed mails can to a large extend also mitigate the
threat. But there are still reasons why signatures can't be used or
need to be verified only at a latter time in the workflow.

OpenPGP had a mitigation against this since 2000 and was widely deployed
by 2003. However S/MIME never implemented this despite of 10 years old
RFCs describing methods for such a mitigation, called authenticated
encryption (AE or AEAD).


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Hello to all,

well it's a good thing, that openPGP shall be included to TB directly.

But ... as the Mozilla wiki [1] states in the FAQ-Section the following:


Q: Will OpenPGP cards be supported for private key storage ?

A: Probably not, because we don't use the GnuPG software that's usually
required to access OpenPGP smartcards.

This will not be usefull for me or my company, as we only use PGP Keys
stored on smartcards.
So I guess we will have to take TB down and find other solutions.

m2c
Juergen


[1] https://wiki.mozilla.org/Thunderbird:OpenPGP:2020

--
Juergen M. Bruckner
juergen@bruckner.tk

On 14.10.2019 18:54, Juergen Bruckner via Gnupg-users wrote:
> Hello to all,
>
> well it's a good thing, that openPGP shall be included to TB directly.
>
> But ... as the Mozilla wiki [1] states in the FAQ-Section the following:
>
>
> Q: Will OpenPGP cards be supported for private key storage ?
>
> A: Probably not, because we don't use the GnuPG software that's usually
> required to access OpenPGP smartcards.

I agree OpenPGP smartcard/token support is a must have, and brought this
up during this during this weekend's OpenPGP summit; please see the
[notes] section "Workshop: Thunderbird & OpenPGP" for some of the
discussion, specifically
"""
Although RNP doesn't support smartcards currently, a potential solution
was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC.
Details need to be discussed, but it would be an optional solution, that
only works if the user has installed software (scd etc.) in addition to
Thunderbird. How would this work? GnuPG as an optional dependency?
Outsourcing smartcard handling to scdaemon (scd), which is available
cross-platform through Unix socket or TCP/IP (windows) with usual user
system protection? Or... extend the RNP library to talk to scd? Needs
discussion and contributors, but that should wait until we're certain
what library TB will use.
"""

References:
[notes]
https://wiki.gnupg.org/OpenPGPEmailSummit201910Notes

--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws

On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said:

> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC.
> Details need to be discussed, but it would be an optional solution, that

Given that TB already has smartcard support it would be easy if the new
code just makes use of that code. Of course the code then needs to
touch the NSS part of Mozilla and can't just go with RNP. That would be
a more integrated solution than any other hack.

Right, separate software will be required but that is the usual case
with smartcards. For example Scute can be used to provide card services
via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will
be much more flexible in regard to smartcard use and how it can interact
with TB via Scute.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

> I have used Enigmail since its inception and have never knowingly
> submitted a log or answered a survey and have always assumed Enigmail
> does not phone home.

It does not.

> Here we disagree. I believe that existing software is not that
> difficult to use. The problem, if there is one, is that most people
> simply aren't interested.

There's excellent academic research into why. I heartily recommend
reading this paper: "Secrecy, Flagging, and Paranoia: Adoption Criteria
in Encrypted Email". Shirley Gaw, Ed Felten, and Patricia
Fernandez-Kelly, out of Princeton University.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.5612&rep=rep1&type=pdf

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 14.10.2019 22:45, Werner Koch wrote:
> On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said:
>
>> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC.
>> Details need to be discussed, but it would be an optional solution, that
>
> Given that TB already has smartcard support it would be easy if the new
> code just makes use of that code. Of course the code then needs to
> touch the NSS part of Mozilla and can't just go with RNP. That would be
> a more integrated solution than any other hack.
>
> Right, separate software will be required but that is the usual case
> with smartcards. For example Scute can be used to provide card services
> via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will
> be much more flexible in regard to smartcard use and how it can interact
> with TB via Scute.

Scute might very well be a good alternative to reach out to, but I'm not
too optimistic regarding the likelihood of getting anything related to
OpenPGP directly into NSS, hence expecting anything that requires
development needs to be done through other vectors.


--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws

Werner Koch writes:

> authenticated encryption is different from signed and encrypted mails.
> There are relative easy attacks on the encryption layer if standard
> encryption modes like CBC (as in S/MIME) are used. Whether this really
> affects users is a different question but they can be used to leverage
> implementation flaws in MUAs to full plaintext leaks. This is known for
> 20 years and made it last year again to the media under the term EFAIL.

I'm confused. I thought the whole efail thing was about crafting a
plain text message that says "Good signature verified" and fools the
user even though it was never run through pgp or had its signature
verified with s/mime.

> Granted, encrypted+signed mails can to a large extend also mitigate the
> threat. But there are still reasons why signatures can't be used or
> need to be verified only at a latter time in the workflow.
>
> OpenPGP had a mitigation against this since 2000 and was widely deployed
> by 2003. However S/MIME never implemented this despite of 10 years old
> RFCs describing methods for such a mitigation, called authenticated
> encryption (AE or AEAD).

AFAICS, that is for encryption+sign. If you just want to sign, it
sounds like you are saying that is broken. I don't see how. You can't
modify the message and keep the hash unchanged, and you can't encrypt a
new hash because you don't have the sender's private key.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> I'm confused. I thought the whole efail thing was about crafting a
> plain text message that says "Good signature verified" and fools the
> user even though it was never run through pgp or had its signature
> verified with s/mime.

I'd suggest reading the Efail paper. The vast majority of the news
coverage was shoddy. Efail included two *completely separate* attacks
in their paper, which the news media overwhelmingly conflated into a
single attack.

I'll call them Efail-1 and Efail-2 here.

Efail-1 was what Werner is talking about here. It was a pretty bad blow
to S/MIME, but far less so to OpenPGP, since OpenPGP has had
countermeasures in place for almost twenty years. Efail-1's impact on
OpenPGP was, is, minimal.

Efail-2 wasn't an attack on OpenPGP at all, but instead showed how
poorly email clients and/or email plugins communicated with GnuPG. It
was possible for GnuPG to give a correct warning that someone was
playing games with the message, and for the email client to disregard
this warning and present it to the user as authentic.

Efail-1 had minimal applicability to GnuPG; Efail-2 had none whatsoever
(except, arguably, some of the messages GnuPG gave were ambiguous: I
think they were, but Werner disagrees).

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Efail-1 was what Werner is talking about here. It was a pretty bad
> blow to S/MIME, but far less so to OpenPGP, since OpenPGP has had
> countermeasures in place for almost twenty years. Efail-1's impact
> on OpenPGP was, is, minimal.
I actually spend a lot of time investigating the impact of EFAIL on
S/MIME and it's my opinion that the real impact has been overblown. In
all my experiments, and I can tell you I have done a lot of them, I have
not been able to force a mail client to actually forward the decrypted
content to a remote system.

The CBC attack is serious because modifying encrypted content is not
something you expect from a security point of view. But the real life
impact is not as big as they wanted us to believe (IMHO). I have asked
the EFAIL authors for examples on real life attacks (of the CBC problem
related to S/MIME) but I never got a real answer whether they were able
to use the attack in real life situation.

I think the problem with the paper was that they discusses two separate
issues. The issue with Efail-2 was serious but that was more an mail
client issue.

Kind regards,

Martijn

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote:
>> I don't know either, but perhaps it is in the debug logs the Enigmail
>> team analyzes?
>
> I have used Enigmail since its inception and have never knowingly
> submitted a log or answered a survey and have always assumed Enigmail
> does not phone home.

I am sure that it doesn't phone home. However, to give an example, I had
a problem some years ago where Enigmail didn't work correctly any more
when a certain other extension was installed, or vice versa. I published
that problem somewhere (can't remember exactly) and got the advice to
turn on Enigmail debugging and send the debug log to a certain email
address or to publish it (again, can't remember). Of course, I followed
that advice (after having examined the log file and having convinced
myself that there was no critical data in it, as expected).

I suppose that the Enigmail team gets quite a lot of such debug logs.
But I still can't tell (and currently don't have the time to
investigate) if those logs can tell which keys had been generated by
Enigmail and which had been generated externally, so the whole thing was
a guess anyway.

>>>> The vast majority of users also don't use GnuPG for
>>>> anything else than email. These users don't care where their key is
>>>> stored, nor which software under the hood is used for the crypto. All
>>>> they care is that encryption works smoothly.
>>>
>>> And this?
>>>
>>
>> I am also not sure about this. As far as it concerns Windows, the first
>> part of the statement may be true.
>
> All the statements might be true. My question was "How do you know?"

Good point. I see.

>> I am not sure where this will lead to. It sounds as if you were
>> suggesting to give up on privacy, encryption and authentication for that
>> reason.
>
> Not at all. My point was that I doubt OpenPGP's inclusion in
> Thunderbird will have a major impact on the number of people encrypting
> their email

I think that even a minor impact would be desirable. The problem is: If
it is done wrong (essential features missing, e.g. subject encryption,
no exchange of keys with external tools, no hardware token support
etc.), it could prevent a large part of today's encryption users from
using encryption in the future, i.e. it even could reduce encryption
prevalence.

Personally, I am not sure what I'd do if the integration of PGP in TB
would be broken (i.e. no subject encryption, no control over key
generation and so on). Theoretically, I could move to another MUA which
provides a reasonable workflow for PGP, but due to pressure of time and
due to flaws or missing features in other MUAs I eventually would have
to stick with TB, even if I couldn't reasonably use PGP any more.

>> While I agree with you that this problem exists and is quite difficult
>> to solve (eventually it needs another decade), I am absolutely sure that
>> bad and difficult software will make it worse, but good and usable
>> software will help in solving it. The fact that the problem exists does
>> not mean that nobody should try to solve it by providing easier-to-use,
>> fully integrated software with reasonable default settings.
>
> Here we disagree. I believe that existing software is not that
> difficult to use. The problem, if there is one, is that most people
> simply aren't interested. Twenty years ago I thought that everyone
> would soon be using end-to-end encrypted email. Twenty years from now
> they still won't be.

Here the integration could really help. For example, keys could be
automatically generated whenever a new email account is created in TB.
Then, when sending the first message using that account, a dialog could
popup asking the user:

"We already have completely setup your PGP keys. Do you want to
authenticate this and further messages, and do you want to attach your
public key to each message so that the correspondents can encrypt their
replies to you, and do you want to upload your public key to server
x.y.z so that everybody can send you encrypted messages and can verify
your signature?"

I bet that 80% of users would answer this dialog by clicking "Yes", and
I think this would really help.

But once again, if too many features are missing in the integration,
this will throw back email encryption prevalence by one or two decades
because TB / Enigmail presumably is the most widespread software for
email encryption, and I am not sure how many users could move to another
MUA if PGP is broken / not fully usable in TB.

>> There are many reasons to think so (the following applies to ProtonMail
>> as well as Tutanota):
>>
>> 1) To actually use those services in a reasonable manner, you have to
>> opt-in for a paid contract. For most of us, this is a matter of
>> principle. Why should we pay for a thing that used to be free all the
>> time? (Note: I don't want to judge that attitude - I am just stating how
>> it is).
>
> <snip>
>
> But "free" email has never been free from the likes of Gmail, Yahoo,
> GMX, etc. While you don't pay a yearly fee, you trade your privacy for
> a few bucks. You open yourself to tracking and targeted advertising.
> Your email is anything but private. A couple years back both Google and
> Yahoo claimed to be working on E2EE. I wonder why it never happened?
>
> The free versions of ProtonMail, Tutanota and Mailfence at least
> preserve your privacy. They aren't monetized through advertising and
> tracking. Instead they sell premium services to people who want more
> capacity or features. Many people I know do email exclusively on their
> smart phones. They don't use an MUA and don't care about POP3, IMAP or
> SMTP. Their view of using email services in a reasonable manner doesn't
> comport with yours or mine.

Correct, but (as I wrote) I didn't want to judge the attitude; I just
wanted to show how it works. Many users reflexively close web pages
immediately as soon as they recognize a $ sign (except online shops and
TV / movie / music sites, of course).

> I hope I am wrong and Thunderbird's OpenPGP implementation is a complete
> success encouraging many more people to encrypt their email. I would,
> however, personally prefer that Thunderbird directly implement GnuPG
> integration instead of going it alone. That would satisfy both casual
> and power users as Enigmail does now.
>
> Will Thunderbird OpenPGP support smart cards like my Yubikey? How about
> a feature like GnuPG's group line or Enigmail's per-recipient rules?
> In-line PGP as well as PGP/MIME? Encrypted subject and the ability to
> turn it on or off? As far as I know, they are all features of GnuPG or
> Enigmail and not required by the OpenPGP specification.
>
> Patrick and company deserve our thanks for many years splendid service
> to the OpenPGP community. So does Werner and his team who created and
> maintain a tool that has satisfied a wide range of users for decades. I
> doubt that yet another proprietary OpenPGP system is what the world needs.

You are speaking out of my heart. Many years ago, I appreciated
Mozilla's decision to provide their own root certificates and
certificate management, because I trusted them much more than Microsoft.

But when it comes to PGP integration, making their own thing for sure is
counter-productive. What Werner and Patrick have created is mature and
completely trustworthy and surely can't be outranked in the foreseeable
time.

Not wanting to make users install additional software isn't a reasonable
argument for re-inventing the wheel, because AFAIK nothing prevents
people from bundling GnuPG with TB in the same installer, and I bet that
even installing these two packages into the same directory and letting
them use the same registry subkeys technically wouldn't be a problem (I
am speaking of Windows here).

So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup
with TB setup? All software they ever could develop themselves will be
inferior compared to that package, at least in the first time.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Binarus wrote on 16.10.2019 10:47:
>
> On 14.10.2019 16:15, Jeff Allen via Gnupg-users wrote:
>>> I don't know either, but perhaps it is in the debug logs the Enigmail
>>> team analyzes?
>>
>> I have used Enigmail since its inception and have never knowingly
>> submitted a log or answered a survey and have always assumed Enigmail
>> does not phone home.
>
> I am sure that it doesn't phone home. However, to give an example, I had

You can be certain that I'd never implement that.
[...]
> I suppose that the Enigmail team gets quite a lot of such debug logs.
> But I still can't tell (and currently don't have the time to
> investigate) if those logs can tell which keys had been generated by
> Enigmail and which had been generated externally, so the whole thing was
> a guess anyway.

Yes, I did and do get quite a lot of debugging log files, and even more
support requests. And I really speak from experience when I say that the
vast majority of the users of Enigmail don't store their private keys on
external devices.

[...]

> So why not take Enigmail, integrate it into TB, and bundle Gpg4Win setup
> with TB setup? All software they ever could develop themselves will be
> inferior compared to that package, at least in the first time.

I have almost 17 years of experience with supporting Enigmail. About 90%
of all support requests that I get turn out to be setup issues with
GnuPG. Interestingly, most of them are on Linux, even though all Linux
distributions I know ship GnuPG. The bundling/shipping would not be a
worry for me. The main problem is the additional complexity that it
brings if you require an external component that you cannot *fully*
control. This covers topics like different behavior of different
versions, but also configuration issues, users rights to install
something on their PC and more. Gpgme may handle some of these issues,
but the fact remains: an external component makes things a lot more
complex, especially for support.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said:

> something on their PC and more. Gpgme may handle some of these issues,
> but the fact remains: an external component makes things a lot more
> complex, especially for support.

Right GPGME handles this all pretty well and I have suggested often
enough that you should move to GPGME so that we can better support
Enigmail. Your comment about external components is right from a
company POV; however Enigmail is also an external component to TB and
thus TB suffers from very similar problem. GpgOL and GnuPG both are
maintained by us and thus I know very well this helps to reduce
friction.

The move to integrate OpenPGP in TB is important but also pretty risky
if it won't work for everyone right away from the start. The big
advantage of TB/Enigmail is that it is cross-platform and often the only
way to have encrypted mail on macOS. I know several media companies who
badly suffered when GpgTools were not able to get their plugin working
on a new macOS version. Their journalists were then forced to use TB
and not their, for whatever reason, beloved apple mailer. Let's hope
that at least of one is always working.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Wed, 16 Oct 2019 10:46, Martijn Brinkers said:

> I actually spend a lot of time investigating the impact of EFAIL on
> S/MIME and it's my opinion that the real impact has been overblown. In
> all my experiments, and I can tell you I have done a lot of them, I have
> not been able to force a mail client to actually forward the decrypted
> content to a remote system.

I recall that you mentioned this in the past and I have not seen any
statement to the contrary. In fact the whole attack is nearly 20 years
old and even back then it was hard to construct a case where the
non-authenticated encryption could be abused. When the PGP folks and me
discussed the attack around the year 2000, we knew that and suggested
signed mails as a solid counter-measurement. The MDC was then
introduced mainly to counter the more or less theoretical attack and to
be on the safe side in case better attacks would be developed.

The media and political coverage (we had working groups and internal
meetings) of the efail paper however required some extra measurements to
take.

> I think the problem with the paper was that they discusses two separate
> issues. The issue with Efail-2 was serious but that was more an mail
> client issue.

I fully agree here. As usual reports about the MUA failures spread for
months without mentioning that all the major MUAs fixed the bug within a
few days or weeks or even had fixed it at the time the paper was
published.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Werner Koch wrote on 16.10.2019 13:54:
> On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said:
>
>> something on their PC and more. Gpgme may handle some of these issues,
>> but the fact remains: an external component makes things a lot more
>> complex, especially for support.
>
> Right GPGME handles this all pretty well and I have suggested often
> enough that you should move to GPGME so that we can better support
> Enigmail. Your comment about external components is right from a
> company POV; however Enigmail is also an external component to TB and
> thus TB suffers from very similar problem. GpgOL and GnuPG both are

Which is why the step to implement OpenPGP in Thunderbird is the right
way to go.

> maintained by us and thus I know very well this helps to reduce
> friction.

We're getting slightly off-topic, but still:
You're perfectly right with everything you say. But you seem to
underestimate the difference between zipping an extension that is pure
JavaScript, and preparing an extension that needs to contain compiled
libraries for multiple platforms in order to cater for all variants of
pre-installed GnuPG installations and all variations of Thunderbird
installations (to be precise, at the very least I'd have to ship for 6
platforms: Win/mac/Linux * 32/64 bit).

Frankly speaking, if I would consider to switch to a library instead of
calling GnuPG directly, I would at first evaluate OpenPGP.js in Enigmail
-- that would be a lot more natural.

-Patrick


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 16.10.2019 13:07, Patrick Brunschwig wrote:
> worry for me. The main problem is the additional complexity that it
> brings if you require an external component that you cannot *fully*
> control. This covers topics like different behavior of different
> versions, but also configuration issues, users rights to install
> something on their PC and more. Gpgme may handle some of these issues,
> but the fact remains: an external component makes things a lot more
> complex, especially for support.

I think this is the usual trade-off. One has to put time

- either in understanding the APIs and command line parameters of a
library / utility, and to keep up with changes, or

- in re-inventing the wheel, which in this case for sure will cost much
more time and eventually produce catastrophic security breaches and
software which is drastically inferior compared to what we have now.

After all, everybody uses libraries and utilities. It is just reasonable
to have an expert work on a library or utility which uses techniques and
mathematical stuff which non-specialists never will understand in
detail, and have the non-specialists use that library or utility,
instead of letting them re-develop the same stuff, probably introducing
all sorts of security flaws and producing inferior software.

When I have a bash script under Linux which invokes a compiler using a
complicated command line, I wouldn't come to the idea to re-develop that
compiler and integrate it directly into bash because that compiler's
command line switches could change in the next version ...

I am still convinced that re-writing GnuPG (including all functions like
hardware tokens, subject encryption etc.) in a secure manner is a
hundred times more complex and a million times more error-prone than
tracking a few changes to its command line switches or error codes ever
could be. Apart from that, there is GpgME, as already has been stated.

Regarding the user rights to install software: That was the reason why I
thought about bundling the installers and installing both parts in the
same directory. Even updates to GnuPG then could be handled by TB's
update system (this is only an educated guess - I don't know if the
licenses would allow this). If TB would use GpgME, this problem even
would not exist in the first place. GpgME would just be another library
lying around in TB's installation directory (under Windows, probably a
DLL) and for sure could be updated via TB's update system.

Just my 2 cents ...

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Binarus wrote on 16.10.2019 17:37:
>
>
> On 16.10.2019 13:07, Patrick Brunschwig wrote:
>> worry for me. The main problem is the additional complexity that it
>> brings if you require an external component that you cannot *fully*
>> control. This covers topics like different behavior of different
>> versions, but also configuration issues, users rights to install
>> something on their PC and more. Gpgme may handle some of these issues,
>> but the fact remains: an external component makes things a lot more
>> complex, especially for support.
>
> I think this is the usual trade-off. One has to put time
>
> - either in understanding the APIs and command line parameters of a
> library / utility, and to keep up with changes, or
>
> - in re-inventing the wheel, which in this case for sure will cost much
> more time and eventually produce catastrophic security breaches and
> software which is drastically inferior compared to what we have now.
>
> After all, everybody uses libraries and utilities. It is just reasonable
> to have an expert work on a library or utility which uses techniques and
> mathematical stuff which non-specialists never will understand in
> detail, and have the non-specialists use that library or utility,
> instead of letting them re-develop the same stuff, probably introducing
> all sorts of security flaws and producing inferior software.
>
> When I have a bash script under Linux which invokes a compiler using a
> complicated command line, I wouldn't come to the idea to re-develop that
> compiler and integrate it directly into bash because that compiler's
> command line switches could change in the next version ...
>
> I am still convinced that re-writing GnuPG (including all functions like
> hardware tokens, subject encryption etc.) in a secure manner is a
> hundred times more complex and a million times more error-prone than
> tracking a few changes to its command line switches or error codes ever
> could be. Apart from that, there is GpgME, as already has been stated.

In all cases, we certainly won't re-write GnuPG or similar. The question
on the table is: do we continue to use GnuPG (be it directly or via
gpgme), or do we use a different OpenPGP implementation (and if yes
which one). There are certainly good arguments for both.

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 16-10-2019 17:37, Binarus wrote:

> - either in understanding the APIs and command line parameters of a
> library / utility, and to keep up with changes, or
>
> - in re-inventing the wheel, which in this case for sure will cost much
> more time and eventually produce catastrophic security breaches and
> software which is drastically inferior compared to what we have now.

There is a 3rd option: build the library (open source anyway) and build
it directly into the product. That has the advantage of using existing,
tested code, allows to dump a lot of complexity for unused edge cases
and prevents the problems with different library versions with changes
between versions.

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Thu, 2019-10-17 at 17:40 +0200, Patrick Brunschwig wrote:
> In all cases, we certainly won't re-write GnuPG or similar. The
> question
> on the table is: do we continue to use GnuPG (be it directly or via
> gpgme), or do we use a different OpenPGP implementation (and if yes
> which one). There are certainly good arguments for both.
>

I am a GnuPG user, not an expert and certainly not a developer, so you
may take my suggestions with a grain of salt.

Following this thread about future OpenPGP support in Thunderbird
prompted me to begin trying other MUAs. Why? Because if Thunderbird
implements its own OpenPGP scheme, I wonder whether it will include
features I consider important like smartcard support. It is unlikely
to have a configuration file like gpg.conf that enables me to fine-tune
both email and file encryption.

For the past couple of days I have been using Evolution. It just works
with GnuPG. I don't know or care how. It encrypts, decrypts and
verifies signatures. There was no set-up required. My Yubikey works
because Evolution calls GnuPG instead of using a proprietary
implementation. AFAIK only GPG does that. Protonmail, Mailvelope,
FlowCrypt, and Mailfence do not. You could probably build in smartcard
support and any other feature I can name, but why grapple with what
GnuPG already does well? Why spend your time trying to head off the
next security threat when Werner & Co. will do it for you?

Enigmail has great features like the key manager and per-recipient
rules. Focus on those. Make Thunderbird encryption easy to use for
novices without driving off more experienced users. Like Enigmail, I
use only a tiny fraction of GPG's commands and options. The fact that
GPG can do things I find esoteric is of little concern to me, but I'm
glad those features are there for people who need them. The complexity
of GnuPG does not make its use complex the average users or for apps
providing GPG front-ends. They simply ignore what they don't need.

The only thing I see that internal OpenPGP accomplishes is saving the
Windows user the task of installing GnuPG. Anyone who uses Thunderbird
knows how to install software. You can probably arrange with Werner
for a permanent link to the latest simple installer. Automatically
check for GnuPG when Thunderbird is installed on Windows. If it isn't
there, offer one-click installation.

I started using Thunderbird because of Enigmail, not the other way
around. I haven't been a fan of some recent developments like pEp and
defaulting to "junior" mode, but I recognize their usefulness to new
users and can easily work around them myself. My take on your original
explanation of the reason for Enigmail's pending demise is that a
changed Thunderbird plug-in scheme makes it more efficient to build
Enigmail functionality into the MUA. Why not stick with that and focus
on what has made Enigmail successful?

Jeff Allen

Jeff Allen via Gnupg-users wrote on 18.10.2019 16:02:
[...]
> My take on your original explanation of the reason for Enigmail's
> pending demise is that a changed Thunderbird plug-in scheme makes it
> more efficient to build Enigmail functionality into the MUA.

That's only the 2nd half of the explanation. 1st and foremost, the
changed plugin scheme comes along with a completely new API (that does
not even exist completely by now). This would require me to rewrite
almost all of Enigmail from scratch. I don't have enough free time for
doing that, nor would I be interested in it. This, and nothing else, was
initially the reason why we started the discussion with the Thunderbird
team.

> Why not stick with that and focus on what has made Enigmail
> successful?
What is the reason in your eyes that made Enigmail successful?

-Patrick

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sat, 2019-10-19 at 17:20 +0200, Patrick Brunschwig wrote:
> Jeff Allen via Gnupg-users wrote on 18.10.2019 16:02:
> [...]
> > My take on your original explanation of the reason for Enigmail's
> > pending demise is that a changed Thunderbird plug-in scheme makes
> > it
> > more efficient to build Enigmail functionality into the MUA.
>
> That's only the 2nd half of the explanation. 1st and foremost, the
> changed plugin scheme comes along with a completely new API (that
> does
> not even exist completely by now). This would require me to rewrite
> almost all of Enigmail from scratch. I don't have enough free time
> for
> doing that, nor would I be interested in it. This, and nothing else,
> was
> initially the reason why we started the discussion with the
> Thunderbird
> team.

I understand not wanting to rewrite Enigmail from scratch using a new
API. If you have neither the time nor the desire to do it, I'm glad
the Thunderbird team is willing to take over. My concern is how
OpenPGP support is to be implemented. IIRC, you stated that it is too
soon to know how much of Enigmail's functionality will be included. To
me that is less important than how much of GnuPG's functionality will
be incorporated. I can live without Enigmail's key manager and per-
recipient rules if there is smartcard support and the ability to
encrypt to multiple keys and to keys without a UID that matches the
recipient's email address. If Thunderbird uses another OpenPGP library
instead of calling GnuPG, I suspect some of those capabilites will
vanish.

>
> > Why not stick with that and focus on what has made Enigmail
> > successful?
>
> What is the reason in your eyes that made Enigmail successful?
>

Enigmail enabled a popular cross-platform email client to interface
with GnuPG with all its capabilities. I've been trying out Evolution
for the past few days. It doesn't have the special features Enigmail
provides, but it does support GPG-encrypted email. It uses the keys on
my Yubikey and aliases in my gpg.conf group lines. It is quite similar
to using the earliest versions of Enigmail. Evolution's main
limitation is that it is Linux only, not cross-platform. Windows and
Mac users are out of luck.

Jeff Allen

On 19.10.2019 17:20, Patrick Brunschwig wrote:
>
>> Why not stick with that and focus on what has made Enigmail
>> successful?
> What is the reason in your eyes that made Enigmail successful?
>

It is the ingenious mixture of integration / ease-of-use on one hand
(setting it up (normally) is a no-brainer, including key generation and
key upload, it allows for per-recipient rules, it provides a nice GUI
for a task which actually is complex, it allows subject encryption, it
allows using hardware tokens, it provides PGP/MIME and PGP/inline, and
it integrates fantastically; heck, the PGP settings even are integrated
into the account settings, exactly where they belong!) and on the other
hand the unlimited possibilities of GnuPG (command line, configuration).

Last, but not least, we must not forget security issues. Implementing
PGP correctly is a hairy task, given the long history of security
problems in different implementations. Werner's implementation has an
excellent reputation, and it's the only one I personally trust
completely. It is exactly the division of tasks which may have
contributed to Enigmail's success more than one would imagine. After
all, email encryption users do care about the underlying engine. We all
know what we would have to expect if the TB team would rewrite the thing
itself (which you have ruled out) or would use some library which hasn't
been tested as rigorously as GnuPG.

Actually, the Enigmail / GnuPG duo is one of the best examples of how
different software parts could work together, thus increasing the
prevalence of both parts by magnitudes, pushing a technique which the
world really needs, and making it usable for the masses. Enigmail /
GnuPG is by fare more than its sum.

Each of the above reasons has made Enigmail such successful (and GnuPG,
or course).

Regards,

Binarus


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Actually, the Enigmail / GnuPG duo is one of the best examples of how
> different software parts could work together, thus increasing the
> prevalence of both parts by magnitudes, pushing a technique which the
> world really needs, and making it usable for the masses. Enigmail /
> GnuPG is by fare more than its sum.

And at the same time, less. Remember what Efail showed us: that the
interface between GnuPG and clients calling it is remarkably subtle and
prone to misinterpretation. It isn't just Enigmail which got bit by
this, either: a *lot* of email clients got hit.

GnuPG has steadfastly refused to create an OpenPGP library programmers
can use directly, on the grounds that security is improved by adding
process separation between the application process and the GnuPG
process. There's a lot to be said for this argument. There's a lot to
be said for the counterargument: that the additional complexity involved
in communicating across a process boundary turns it into a false savings.

I'm not sure which one I believe, myself.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

>> GnuPG has steadfastly refused to create an OpenPGP library programmers
>> can use directly,
>
> I was under the impression that gpgme is just such a library.

It is not. Under the hood, GPGME works by launching an entirely new
process and directing it via interprocess communication.

Hopefully this puts the rest of my paragraph in perspective:

"... on the grounds that security is improved by adding
process separation between the application process and the GnuPG
process. There's a lot to be said for this argument. There's a lot to
be said for the counterargument: that the additional complexity involved
in communicating across a process boundary turns it into a false savings."

Regardless of whether you interface with GnuPG directly (as Enigmail
does) or through a library (as GPGME-using applications do), you're
still running GnuPG in a separate process and communicating across a
process boundary.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Werner's implementation has an excellent reputation, and it's the only one
> I personally trust completely.

You state this so matter-of-factly, I feel compelled to point out that among
cryptographers, libgcrypt's reputation is not all that great...

https://twitter.com/ciphergoth/status/1179959883589771265

- V

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users