Mailing List Archive

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