[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: removing enigmail from jessie?

On 2018-09-27 10:51:25, Antoine Beaupré wrote:
> So thinking about this again, I see three options:
>  1. Make Enigmail work with GnuPG 2 in Debian and ship the result in
>     jessie-securtiy. As mentioned above, I think this has huge
>     implications and risks breaking unrelated software, so it's not
>     really an option.
>  2. Same as #1, but ship the updates through sloppy backports. We could
>     then have gnupg2.2 and enigmail live together. It could still break
>     things, but at least we could say "told you so" and parade around
>     like it's not our fault. Obviously not ideal either.
>  3. Package the missing dependencies for openpgp.js that make Enigmail
>     work without GnuPG. That's another big undertaking and it requires
>     making Javascript packages cross NEW, which is a challenge onto
>     itself. I've done the little magic thing to list the dependencies
>     and document this in #787774 but we're far from having this
>     ready. But at least this would work without damaging unrelated
>     software.
>  4. Just give up on Enigmail in jessie and remove it from the list of
>     supported packages. Enigmail is listed in the addons and works well
>     from there as it's pure Javascript. I'm not sure how that could be
>     handled: just removing the package from the archive would leave
>     people without upgrades or a notification that the package is gone
>     (a recurring problem we should solve, IMHO).

>From apo's comment and discussions with one of the enigmail maintainers
(dkg), a fifth option came up:

 5. backport enigmail with the patches to GPG 2.0. the reason the
    build-dep version was bumped is there are critical security issues
    in the way GPG 2 operates under certain circumstances which are used
    by Enigmail (at least T4017 and T4018 in GnuPG's bts)

This seems like the best approach right now. Yes, enigmail works with
GPG 2.1 in stretch, but it doesn't mean it's safe. It seems, in fact,
particularly vulnerable to arbitrary key injection if I read the above
bug reports correctly.


In any case, backporting Enigmail to stretch or jessie is not simple .

The problem right now is that Enigmail itself is in a state of flux. The
versions compatible with TB 60 are the latest versions and those are,
well, in development, to put it mildly. For example, from what I
understand, OpenPGP.js is used by Enigmail, but not everywhere: Enigmail
still requires a functioning GnuPG installation, which surprised
me. [Autocrypt] support is still in development and Debian CI breaks as
the test suite fails in some critical code paths which make the current
implementation more or less insecure.

[Autocrypt]: https://autocrypt.org/

So in short, according to dkg, to get Enigmail working properly, we need
to fix the test suite, which involves going deep in some pretty nasty
multilayered, vendored and copied Javascript code.

The alternative, of course, would be to fork off some Enigmail version
and remove Autocrypt support for stable/oldstable. But then we end up
living with that fork for a long time as well.

So right now I've taken the approach of fixing stuff for unstable and
helping dkg deal with this mess. I'll be reviewing his code in the hope
we can push an update forward.

In the meantime, of course, work on TB60 can proceed - worse case an
upload happens before enigmail is ready, like happened in enigmail but
obviously it would be better to coordinate this.

Whee, what a mess! :)


If you have come here to help me, you are wasting our time.
But if you have come because your liberation is bound up with mine, then
let us work together.    - Aboriginal activists group, Queensland, 1970s

Reply to: