23/04/14 16:51, Nick Mathewson wrote:
> My goal is to get out a new alpha with the blacklist this week, and an
> 0.2.4 release by the end of the month.
>
> This is a goal; I don't know if I'm going to be able to make it, and I
> can't make mpromises there.
The timing of this is clearly pretty bad for the Tails 1.0 release,
whose image is planned to be built on 2014-04-27. Given Nick's wording,
I think we must proceed by assuming that it won't be ready in time for
that. None of the possibilities this leaves us look very appealing.
Releasing Tails as planned on 2014-04-29, without further action on this
issue, means that Tails 1.0 will ship with a version of Tor that will be
out-dated in just a few days (possibly even upon release). In
particular, Tails 1.0 users would be vulnerable to forged consensuses
*if* enough Tor authorities' signing and identity keys were stolen using
Hearbleed [1]. All this IMHO looks pretty awkward for such a monumental
milestone in Tails' history. If we decide it's serious enough for an
early 1.0.1 bugfix-release, it also looks pretty bad. If we don't, Tails
users will be vulnerable for ~six weeks, until the planned 1.1 release,
which, well, also looks bad.
Delaying the release until the new Tor is out is another possibility,
with it's own set of issues. As I stated in the "Release schedule for
Tails 1.0" thread [2], "I will be completely unavailable from early
morning 2014-04-30 until 2014-05-05". Hence any delay for the 1.0
release means that I can prepare the image earliest on 2014-05-05. I
could at least build the iceweasel packages as planned, and prepare
other things, which would save some time; with some dedicated testers
(available late on 2014-05-05 and early on 2014-05-06) we may have a
release as early as 2014-05-06. That would still leave Tails users
vulnerable to any Firefox issues for an entire week, and there's still
no guarantee (again due to Nick's wording) that we'll have the new Tor
release by then.
> If you like, it could be entirely reasonable to backport the code in
> question; the relevant commits are:
>
> 50ad3939242885b1a1a11688abd0c9756631747f
> 46cf63bb42f2818201bc0c39036f2c17e210fcdb
> 2ce0750d21d04c39a5a948b3d96203d8f68ae7ad
> ef3d7f2f97caf961effd7935dd3231e6bba62ca5
This would enable us to release Tails 1.0 as planned, and at least
protect Tails 1.0 users against forged consensuses from
Heartbleed-compromised authorites, i.e. we're covered for Tor ticket
#11464. The other stuff currently fixed in the main-2.4 branch since
0.2.4.21 are:
o Minor bugfixes:
- Avoid sending an garbage value to the controller when a circuit is
cannibalized. Fixes bug 11519; bugfix on 0.2.3.11-alpha.
- Stop leaking memory when we successfully resolve a PTR record.
Fixes bug 11437; bugfix on 0.2.4.7-alpha.
- Fix a compilation error when compiling with --disable-cuve25519.
Fixes bug 9700; bugfix on 0.2.4.17-rc.
- Avoid 60-second delays in the bootstrapping process when Tor
is launching for a second time while using bridges. Fixes bug 9229;
bugfix on 0.2.0.3-alpha.
- Give the correct URL in the warning message that we present
when the user is trying to run a Tor relay on an ancient version
of Windows. Fixes bug 9393.
o Documentation:
- Correctly document that we search for a system torrc file before
looking in ~/.torrc. Fixes documentation side of 9213; bugfix
on 0.2.3.18-rc.
In other words, nothing serious. For an overview of other potential
fixes that may end up in the next 0.2.4 Tor release, see:
<
https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~024-backport>.
After a quick look, nothing stood out as important for Tails' use cases
but I've nevertheless asked the Tor devs for a confirmation. If I'm
correct, this backporting solution may be the best compromise for us.
Thoughts?
Cheers!
[1]
https://lists.torproject.org/pipermail/tor-dev/2014-April/006663.html
[2]
https://mailman.boum.org/pipermail/tails-dev/2014-April/005449.html
