Tails

#1 Updated by sajolida 2016-11-26 11:56:36

This is what I wrote to someone by email:

We've been considering switching to 64-bit for years. Doing so is not
only a disadvantage for people with 32-bit computers but also has
advantages for people with 64-bit:

- 64-bit processors are more interesting from a security point of view,
for example it's harder to brute force offsets/addresses, ASLR becomes
stronger in that sense as is PIE support.

- Removing 32-bit makes our ISO images and automatic upgrades a bit
smaller for everybody. For example 3.0 is ~50MB bigger than 2.7 despite
being based on a new version of Debian and GNOME. It's not much on a
full ISO but it will make a bigger difference in automatic upgrades and
this is important for people on slow Internet connections.

- Having two kernels created problems in the past on some hardware for
both people with both 32-bit and 64-bit processors, for example:
https://labs.riseup.net/code/issues/11518. Releases with a single
architecture will be more robust.

- More issues dealing with a multiarch ISO image also means less time
for us to work on other issues that might affect more people.

It's very hard for us to rely on good statistics on what kind of
hardware our users depend upon and we've always tried to remain
compatible with old hardware as much as possible. And many of the Tails
users we have around us don't have much money either.

The only data source that we could base ourselves are the bug reports
that we receive through WhisperBack and seeing which hardware people are
using. We've been doing this since 2014 and, as expected, 32-bit
computers are slowly replaced by 64-bit computers:

|        | 32-bit |  % | 64-bit |  % |
| 2014Q2 |     31 | 15 |    171 | 85 |
| ...    |     .. | .. |    ... | .. |
| 2016Q3 |     18 |  7 |    215 | 92 |

3.0 will be most probably released in the second half of 2017, so the
number of 7% that has been quite stable over the past year will continue
to go down and we expect to disrupt only 5% of our user base. We believe
that at that point, the benefit of being 64-bit only overweight the
disadvantages of depriving the few remaining 32-bit users of Tails.

#6 Updated by intrigeri 2017-06-04 14:55:31

As promised, here’s some input. Of course, I’ll let it up to you to judge what’s relevant for release notes or not:

• Good news first! Actually it looks very much like the 3.0 ISO will be reproducible: at least with the tiny set of build environment variations we’ve tested, both testing and devel branches now are :) Ulrike is working on a dedicated blog post for end-users about it, not sure about the exact timing vs. the 3.0 release.
• Tor Browser 7.0 i.e. Firefox 45.x → Firefox 52.x (ask anonym pointers to their release notes if you’d rather not find them yourself)
• Debian 9 (Stretch) will be released on June 17. It’s the first time in our history that we release Tails based on the new Debian release at about the same time as that Debian release. E.g. Tails 2.0 was released 9 months after Debian Jessie, and Tails 1.1 was released 14 months after Debian Wheezy. Might be a good time to write something about the importance of good relationships to upstream, not sure how to word it for end users; I could think more about it if you find it potentially useful.
• Lots of people requested us to include KeePassX 2.x, so I guess it’s visible and beneficial for them (primarily for cross-platform inter-operability, from what I could gather).
• Fixed UEFI boot on some machines (Bug #12511).
• Bug #12363 is an important security fix, not visible to most users though but perhaps it’s worth mentioning that we have this topic in mind.
• I think that upgrading X.Org makes Tails usable on lots of machines we could not support in 2.x. It’s gonna be quite some work to come up with a list though, so perhaps it’s not worth it. If you want to give it a try, I think the most relevant sources of information about this can be found there:
  • the diff (master..testing) of the known issues page, that I sometimes cleaned up a bit when I was reported improvements
  • the list of resolved tickets for each Tails_3.0* target version
  • the list of Fix Committed tickets for 3.0
• in Debian Stretch, most binaries are hardened with PIE , which solves in great part one of the major complains security experts had about Debian/Tails: PIE is needed to take advantage of ASLR. I have no stats wrt. the ones we ship in Tails (Feature #6918); I expect it would take me a few hours to get this number; let me know if you think it’s worth my time (I doubt it).

I’ve had a quick look at the rough draft in the topic branch, and could spot nothing that seemed technically wrong or out of place, except perhaps:

• the on-screen keyboard in the new Greeter only supports a few keyboard layouts so it’s usefulness is somewhat limited;
• the screen reader support in the new Greeter may be too poorly usable for us to boast about it: Feature #11664, Bug #12526. Perhaps we can mention that the new Greeter “paves the way” for major accessibility improvements.

That’s all for today :)

Regarding “Major versions of included software”, if you want I could have another look at the diff, in case some upgrade of barely known / plumbing / low-level software are incidentally user-visible enough to be worth mentioning. This should not take me more than 15 minutes.

Let me know if any of the above is unclear, or if you need other input from me.

#8 Updated by intrigeri 2017-06-07 17:27:43

Quoting https://blog.torproject.org/blog/tor-browser-70-released:

Most notably we hope having Mozilla's multiprocess mode (e10s) and content
sandbox enabled will be one of the major new features in the Tor Browser 7.0
series, both security- and performance-wise. While we are still working on the
[sandboxing part for Windows](https://bugs.torproject.org/16010) (the e10s
part is ready), both Linux and macOS have e10s and content sandboxing enabled
by default in Tor Browser 7.0. […]

The highlights in our tracking and fingerprinting resistance improvements are:
cookies, view-source requests and the Permissions API are isolated to the
first party URL bar domain now to enhance our tracking related defenses.

#9 Updated by sajolida 2017-06-07 21:21:08

Cool! That’s super useful at this point. Bug #12363 points me to a ticket related to the documentation of Tails Greeter and nothing related to an “important security fix”. Which one were you talking about?

I don’t think it’s worth going through the diff again to hunt for a few potential missing changes.

#10 Updated by intrigeri 2017-06-08 07:44:21

> Cool! That’s super useful at this point.

:)

> Bug #12363 points me to a ticket related to the documentation of Tails Greeter and nothing related to an “important security fix”. Which one were you talking about?

I blindly trusted the changelog that was wrong (fixing that). It’s rather Bug #12362.

#13 Updated by sajolida 2017-06-10 12:18:27

> * I find “at the same time as its new version of Debian” unclear, probably because of the “its”. How about “at the same time as the new version of Debian it is based on”?

Applied.

> * I’m not sure what you mean with the “stability benefits” of moving to a 64-bit userspace. Did you mean sustainability? (Sorry if I wrote that myself somewhere and forgot the rationale…)

In /news/Tails_3.0_will_require_a_64-bit_processor you’re mentionning
that the previous situation was leading to “compatibility issues”.
So I thought that using “stability” instead of “sustainability” could
describe the same in a tiny bit more user centric way. Now I replaced
this with “reliability” which might be less ambiguous.

If you still don’t like it, please replace it with “sustainability” :)

> * AFAIK, the sandboxing enabled in Firefox 52esr is limited to a small part of the browser (compared to more recent Firefox, not even mentioning Chrome). So I would boast a little bit less about it, and mention it “paves the way” for future sandboxing, rather than claiming exploitation resistance in the current state of things.

Applied.

> * I’m a little bit concerned that we’re documenting how to re-enable the Pidgin “systray” icon, without mentioning the risk of re-introducing buggy behavior that might have been fixed by removing it. Now, given the data we have is pretty thin, I dunno how to phrase this in a both correct and useful way… sorry :/

Removed.