Hi!
On Wed, 11 Jun 2014, Adam D. Barratt wrote:
> The next point release for "wheezy" (7.6) is scheduled for Saturday,
> July 12th. Stable NEW will be frozen during the preceding weekend.
I propose to update Tor in stable to the version that is now in jessie.
This would be a jump to the next major version of tor, not just a
patch release update.
The Tor version in stable is 0.2.3.25, the latest version of the
old 0.2.3.x tree of Tor releases. The current stable Tor tree is
0.2.4.x, released as stable in December, with the current update
being .22 from May.
There's, of course, a whole bunch of reasons why 0.2.4.x is
oh-so-much better than 0.2.3.x.
One key-point is that about a quarter of the Tor network (just
considering the relays, not any clients), is on 0.2.3.25, presumably
because they run Debian stable. If they all upgraded to the 0.2.4.x
tree, the network as a whole would become a lot more secure as
0.2.4.x allows clients to use stronger crypto for connections built
through these nodes.
Also, Tor upstream is not entirely sure what they would want to
backport to 0.2.3.x in order to call it as DoS-resistant as 0.2.4.x.
That is to say, they are not aware of any arbitrary-code-execution
bugs that affect 0.2.3.x, but nobody knows which of the
DoS/resource-leak bugs that were fixed in the new tree could or
should be backported:
| And indeed, we're basically done backporting fixes to 0.2.3. For
| anything short of a remote overflow, we're probably not fixing
| it.
Obviously, since this is a major upstream version jump, reviewing the
diff is not feasible.
Even going over the upstream changelog took a good long while. That
resulted in a number of things we'd really like to have.Changes
include things like rejecting authority signing keys that might have
been exposed due to heartbleed, TLS ciphersuits now being chosen by
relays rather than clients (client lists have been chosen mainly for
anti-fingerprinting purposes), always clearing bignums before freeing
them, TLS 1.1 and 1.2 support, turning off client-side DNS cache by
default (that fixes a huge linkability issue for clients), and much
more. I can clean-up and provide a full(er) list on request.
I don't expect the hand-full of reverse dependencies would have any
problems with the version jump, and from a relay-operator or end-user
point of view not much directly visible has changed.
The default contents of the /etc/tor/torrc conffile have changed
slightly. (In fact, the diff is so tiny - one date change and one
typo fix in comments - that we could consider reverting that change
to cut down on dpkg propmts if you prefer.) Existing configuration
files are expected to continue to work in all cases.
Is this update something we can do?
Thanks for your consideration,
weasel
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140616185313.ga17...@anguilla.noreply.org
