Re: p≡p foundation and Enigmail
acelists at atlas.sk
Sun Nov 26 15:03:38 UTC 2017
----- Pôvodná správa -----
Predmet: Re: p≡p foundation and Enigmail
Od: Damiano Boppart <damiano at pep-security.net>
Pre: tb-planning at mozilla.org
Dátum: Sun, 26 Nov 2017 14:50:37 +0100
> On 24.11.17 23:04, Joshua Cranmer 🐧 wrote:
>> So, if I understand it right, this means we're farming work out to
>> another process that's running a library that's using another application?
>> Everything should be made as simple as possible, but not simpler
> - by Roger Sessions, who attributed it to Albert Einstein
> As far as Thunderbird or Enigmail is concerned, there is just a REST API
> made available by a process running locally as the same user as TB.
> As far as using another "application" is concerned, yes and no. We
> interface with GnuPG through the library GPGME. But, the API of GPGME
> depends not only on the version of GPGME, but also on the version of
> GPG. Being a bit imprecise here, I say that "we depend on GPGME and GPG"
> for short. GPGME is by the same developers as GPG, though not all
> third-party distributions (e.g. such as GPG4WIN or GPG Tools) include GPGME.
Yes, but PEP was supposed to be easy and transparent, for people who
can't be bothered to setup PGP, certificates, etc.
Starting a separate daemon in the user session (reportedly before TB
startup) is non-trivial in Linux (for the various desktop environments),
which you seem to confirm by only supporting 4 Linux distros (mine not
on the list). It may also not be wished by the user - why running
another daemon while not being used (e.g. when TB is closed). Also, if
the PEP core/engine is not distributed with Enigmail, how is it
distributed? Should the system admin install it? Can the user install it
on his own? Is this another dependency that the user needs to care
about? Then he could already install pgp+Enigmail if he cared.
Enigmail has already enough troubles to have to call gnupg (and gnupg2
and 'pinentry' and whatever), a procedure which changed through the
times, making working configurations no longer working. Even I had to
contact the Enigmail author and be referred to new documentation on how
to change the configuration to get messages to decrypt again.
GPGME is also distributed as a separate package from GPG, so it again
may not be available.
So I surely understand you want to share code that is the same for all
platforms, which is fine. But I fail to see how in this setup (adding
even more external dependencies) PEP makes things any simpler. I think
from the talks in the past we somehow assumed PEP would be completely
contained within Enigmail, which would be bearable, but even installing
an extension is a no-go for some users and we then can't expect PEP will
be available at the receiving party. Yes, we could make Enigmail bundled
with TB in the same way as Lightning. So if that is the plan or the
prerequisite, I don't think this idea has seriously hit the developers'
More information about the tb-planning