Re: p≡p foundation and Enigmail

Patrick Brunschwig patrick at
Sun Nov 26 16:27:32 UTC 2017

On 26.11.17 16:03, ace wrote:
> ----- Pôvodná správa -----
> Predmet: Re: p≡p foundation and Enigmail
> Od: Damiano Boppart <damiano at>
> Pre: tb-planning at
> 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),

Nobody said that. The daemon is started by Enigmail if it doesn't run,
similarly to how gpg-agent is launched if needed.

> 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? 

The idea is that Enigmail would download pEp (and gpg) if needed and
install (or better: unzip) everything without requiring root rights in
the user's profile directory by Enigmail. That's similar to how the
Setup Wizard installs gpg if it's not available.

> Is this another dependency that the user needs to care about? 

No. If pEp doesn't work or is unavailable, then Enigmail will fall back
to its regular mode that you know already.

> 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.

Yes, GnuPG setup - especially on Linux systems - is a challenge. But
there is currently no better cross-platform implementation of OpenPGP
available, if you want to use it from C/C++ code.

> GPGME is also distributed as a separate package from GPG, so it again
> may not be available.

It's part of pEp, it is not needed separately.

> 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'
> mailinglists yet.

The first step is to prove that Enigmail with pEp is working, and that
it's really easier than Enigmail without pEp. If we succeed,
Enigmail/pEp can hopefully be integrated one day in TB. If we don't
succeed, then Enigmail without pEp will continue to work.


More information about the tb-planning mailing list