This is my monthly Debian LTS .

Python updates

Uploaded DLA-1519-1 and DLA-1520-1 to fix
CVE-2018-1000802, CVE-2017-1000158, CVE-2018-1061 and
CVE-2018-1060 in Python 2.7 and 3.4. The latter three were
originally marked as no-dsa but the fix was trivial to backport. I
also found that CVE-2017-1000158 was actually relevant for 3.4 even
though it was not marked as such in the tracker.

CVE-2018-1000030 was skipped because the fix was too intrusive
and unclear.

Enigmail investigations

Security support for Thunderbird and Firefox versions from jessie has
stopped upstream. Considering that the Debian security team bit the
bullet and updated those in stretch, the consensus seems to be that
the versions in jessie will also be updated, which will break
third-party extensions in jessie.

One of the main victims of the
XULocalypse is
Enigmail, which completely stopped working after the stretch
update. I looked at how we could handle this. I first proposed to
wait before trying to patch the Enigmail version in jessie since it
would break when the Thunderbird updates will land. I then detailed
five options for the Enigmail security update:

  1. update GnuPG 2 in jessie-security to work with Enigmail, which
    could break unrelated things

  2. same as 1, but in jessie-backports-sloppy

  3. package the JavaScript dependencies to ship Enigmail with
    OpenPGP.js correctly.

  4. remove Enigmail from jessie

  5. backport only some patches to GPG 2 in jessie

I then looked at helping the Enigmail maintainers by reviewing the
OpenPGP.js packaging through which I found a bug in the
JavaScript packaging toolchain, which diverged into a patch in
npm2deb to fix source package detection and an Emacs function to
write to multiple files. (!!) That work was not directly useful to
Jessie, I must admit, but it did end up clarifying which dependencies
were missing for OpenPGP to land, which were clearly out of reach of a
LTS update.

Switching gears, I tried to help the maintainer untangle the
JavaScript mess between multiple copies of code in TB, FF (with
itself), and Enigmail’s process handling routines; to call GPG
properly with multiple file descriptors for password, clear-text,
statusfd, and output; to have Autocrypt be able to handle “Autocrypt
Setup Messages” (ASM) properly (bug #908510); to finally make the
test suite pass. The alternative here would be to simply rip Autocrypt
out of Enigmail for the jessie update, but this would mean diverging
significantly from the upstream version.

Reports of Enigmail working with older versions of GPG are deceiving,
as that configuration introduces unrelated security issues (T4017
and T4018 in upstream’s bugtracker).

So much more work remains on backporting Enigmail, but I might work
for the stable/unstable updates to complete before pushing that work
further. Instead, I might focus on the Thunderbird and Firefox
updates next.


I worked more on the GnuTLS research as a short followup to our
previous discussion.

I wrote the researchers who “still stand behind what is written
in the paper” and believe the current fix in GnuTLS is
incomplete. GnuTLS upstream seems to agree, more or less, but point
that the fix, even if incomplete, greatly reduces the scope of
those vulnerabilities and a long-term fix is underway.

Next step, therefore, is deciding if we backport the patches or just
upgrade to the latest 3.3.x series, as the ABI/API changes are minor
(only additions).

Other work

I have, this month again, been quite spread out on many unrelated
projects unfortunately.


I’ve played around with the latest attempt from the free software
community to come up with a “federation” model to replace Twitter and
other social networks,
Mastodon. I’ve had an account for a while
but I haven’t talked about it much here yet.

My Mastodon account is linked with my Twitter account
through some unofficial Twitter cross-posting app which more or
less works. Another “app” I use is the toot client to connect my
website with Mastodon through feed2exec.

And because all of this social networking stuff is just IRC 2.0, I
read it all through my IRC client, thanks to Bitlbee and Mastodon
is (thankfully) no exception. Unfortunately, there’s a problem in my
hosting provider’s configuration which has made it impossible to read
Mastodon status from Bitlbee for a while. I’ve created a test profile
on the main Mastodon instance to double-check, and indeed, Bitlbee
works fine there.

Before I figured that out, I tried upgrading the Bitlbee Mastodon
(for which I also filed a RFP) and found a
regression has been introduced somewhere after 1.3.1. On the plus
side, the feature request I filed to allow for custom visibility
statuses from Bitlbee has been accepted, which means it’s now possible
to send “private” messages from Bitlbee.

Those messages, unfortunately, are not really private: they are
visible to all followers, which, in the social networking world, means
a lot of people. In my case, I have already accepted over a dozen
followers before realizing how that worked, and I do not really know
or trust most of those people. I have still 15 pending follow requests
which I don’t want to approve until there’s a better solution, which
would probably involve two levels of followship. There’s at least
one proposal to fix this already.

Another thing I’m concerned about with Mastodon is account
: what happens if I’m unhappy with my current host? Or if
I prefer to host it myself? My online identity is strongly tied with
that hostname and there doesn’t seem to be good mechanisms to support
moving around Mastodon instances. OpenID had this concept of
delegation where the real OpenID provider could be discovered and
redirected, keeping a consistent identity. Mastodon’s proposed
solutions seem to aim at using redirections or at least
informing users your account has moved which isn’t as nice, but
might be an acceptable long-term compromise.

Finally, it seems that Mastodon will likely end up in the same space
as email with regards to abuse: we are already seeing block lists
show up to deal with abusive servers, which is horribly reminiscent of
the early days of spam fighting, where you could keep such lists (as
opposed to bayesian or machine learning). Fundamentally, I’m worried
about the viability of this ecosystem, just like I’m concerned about
the amount of fake news, spam, and harassment that takes place on
commercial platforms. One theory is that the only way to fix this is
to enforce two-way sharing between followers, the approach taken by
Manyverse and Scuttlebutt.

Only time will tell, I guess, but Mastodon does look like a promising
platform, at least in terms of raw numbers of users…

The ultimate paste bin?

I’ve started switching towards as a pastebin. Besides the
unfortunate cryptic name, it’s a great tool: multiple pastes are
deduplicated, large pastes are allowed, there is a (limited)
server-side viewing mechanism (allowing for some multimedia), etc. The
only things missing are “burn after reading” (one-shot links) and
client-side encryption yet the latter is planned.

I like the simplistic approach to the API that makes it easy to use
from any client. I’ve submitted the above feature request and a
trivial patch so far.

ELPA packaging work

I’ve done a few reviews and sponsoring of Emacs List Packages (“ELPA”)
for Debian, mostly for packages I requested myself but who were so
nicely made by Nicolas (
elpa-auto-dictionary). To better figure out which packages are
missing, I wrote this script to parse the output from an ELPA and
compare it with what is in Debian. This involved digging deep into the
API of the Debian archive, which in turn was useful for the JavaScript
work previously mentioned. The result is in the
firefox page which lists all the extensions I use
and their equivalent in Debian.

I’m not very happy with the script: it’s dirty, and I feel dirty. It
seems to me this should be done on the fly, through some web service,
and should support multiple languages. It seems we are constantly
solving this problem for each ecosystem while the issues are

Firefox privacy issues

I went down another rabbit hole after learning about Mozilla’s plan to
force more or less
mandatory telemetry in future versions of
Firefox. That got me thinking of how many such sniffers were in
Firefox and I was in for a bad surprise. It took about a day to
establish a (probably incomplete) list of settings necessary to
disable all those trackers in a temporary profile starter,
originally designed as a replacement for chromium --temp-profile but
which turned out to be a study of Firefox’s sins.

There are over a hundred of about:config settings that need to be
tweaked if someone wants to keep their privacy intact in Firefox. This
is especially distressing because Mozilla prides itself on its privacy
politics. I’ve documented this in the Debian wiki as well.

Ideally, there would be a one-shot toggle to disable all those
things. Instead, Mozilla is forcing us to play “whack-a-mole” as they
pop out another undocumented configuration item with every other

Other work

Source link


Please enter your comment!
Please enter your name here