September 2018 report: LTS, Mastodon, Firefox privacy, etc

  1. blog
  1. Debian Long Term Support (LTS)
    1. Python updates
    2. Enigmail investigations
    3. Other work
  2. Other free software work
    1. Mastodon
    2. The ultimate paste bin?
    3. ELPA packaging work
    4. Firefox privacy issues
    5. Other work

Debian Long Term Support (LTS)

This is my monthly Debian LTS report.

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.

GnuTLS

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

Other free software work

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

Mastodon

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 bridge (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 migration: 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 ptpb.pw 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-markdown-toc, 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 similar...

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

Other work

RSS
Firefox privacy resources

There's the addon Privacy Settings by Jeremy Schomery but it was last updated 9 months ago.

Mozilla's wiki has an exhautive page on privacy tweeks but I agree with the whack-a-mole image.

Another page with similar info is in form of a github gist.

Finally, there's this ongoing comprehensive user.js template for configuring and hardening Firefox privacy, security and anti-fingerprinting and wiki.

Most of these links come from the https://restoreprivacy.com/firefox-privacy/ page and do not reflect my personnal experience.

Comment by Robin —
There is no cat

You might have heard this quote attributed to Einstein:

You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat.

I first heard it when wifidog was born, after nocat. Well, turns out, it might have originated in a "fortune": https://quoteinvestigator.com/2012/02/24/telegraph-cat/

Thought you might find this interesting.

Comment by Robin —
cat quote
indeed, i do know about that quote! I've actually had that in my fortune database for about 6 years and i've always wondered if it was an accurate attribution. i've now marked is as apocryphal, thanks! :)
Comment by anarcat —
Comments on this page are closed.
Created . Edited .