In light of the technical obstacles that prevent packaging Tor Browser (see below), I propose operating a repository that relies on The Update Framework (TUF) [0]. TUF is a secure updater system designed to resist many classes of attacks [1]. Its based on Thandy (the work of Roger, Nick, Sebastian and others).
The advantage of this proposal is that (Tor based distros and others in general) can finally retire the TBB downloaders and shed the maintenance burden. Also there is no need to re-invent secure download mechanisms when there is a project that already covers this.
***
Rehash of previous discussions on the topic:
The major reasons why TBB is not in the Debian repository:
* The reproducible build system depends on a static binary image of (then Ubuntu) which runs counter to Debian policy.
* TBB is based on Firefox ESR and not Iceweasel which also runs into the "no duplicate source package" policy of Debian.
Reasons for unavailability of TBB .deb in the Tor Project APT repository:
* The break neck speed of development
* Its not easily packaged and the amount of effort needed is better spent otherwise.
***
[0] https://theupdateframework.github.io/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md
On Fri, Jun 10, 2016 at 04:22:04PM +0200, bancfc@openmailbox.org wrote:
In light of the technical obstacles that prevent packaging Tor Browser (see below), I propose operating a repository that relies on The Update Framework (TUF) [0]. TUF is a secure updater system designed to resist many classes of attacks [1]. Its based on Thandy (the work of Roger, Nick, Sebastian and others).
The README sounds good, but it being implemented in python adds quite a heavy additional dependency. Isn't the same achievable by means of a git library, using signed git commits and additional consistency checks (git fsck or something). This should only allow for updates which are forward in time and signed by the correct authors. Additionally you could check(sum) the commit times, thus ensuring that an update didn't get intentionally cut-off at last month's insecure version. This would address most of the points you list in https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt
Additionally, if git is only used for the metadata, leaving to the user to decide when to download or torrent a certain new hashed version, then it can provide daily or weekly keep-alive commits, making it hard for an attacker to usurp the rare condition by which a torbrowser that has not been used for months needs updates and could be lured into fetching an insecure version. Maybe the git library needs to be hardened regarding "endless data" and "slow retrieval" attacks, which would then be something any git user would appreciate.
I personally am not affected by the debian issues. Since I never understood why it should make sense to trust the debian build process I happily enjoy MeisterP's excellent torbrowser overlay for Gentoo. I even get to configure it so that it uses my Tor router rather than any embedded one.
carlo von lynX lynX@time.to.get.psyced.org writes:
The README sounds good, but it being implemented in python adds quite a heavy additional dependency.
My understanding is that TUF is two things: a spec, and a reference implementation (in Python). I'm sure other implementations would be welcome -- and, e.g., Docker Notary is such an implementation (in Go) as I understand it.
meejah:
carlo von lynX lynX@time.to.get.psyced.org writes:
The README sounds good, but it being implemented in python adds quite a heavy additional dependency.
My understanding is that TUF is two things: a spec, and a reference implementation (in Python). I'm sure other implementations would be welcome -- and, e.g., Docker Notary is such an implementation (in Go) as I understand it.
I've read up on TUF for F-Droid. Its a good discussion of the issues, but the TUF software itself is only really applicable in a narrow range of situations. For example, its in Python, so that's a no-go for Android or iOS, and somewhat difficult on Windows.
I've always treated TUF as a nice overview of the issues. F-Droid has long implemented most of it, and now we are implementing the remaining key bits, and a couple of parts just seem like vastly too much effort in the short or medium term, versus the actual risk.
.hc
bancfc@openmailbox.org:
Rehash of previous discussions on the topic:
See #3994.
The major reasons why TBB is not in the Debian repository:
- The reproducible build system depends on a static binary image of (then
Ubuntu) which runs counter to Debian policy.
It's likely not a problem if built from source.
- TBB is based on Firefox ESR and not Iceweasel which also runs into the "no
duplicate source package" policy of Debian.
I've discussed this with Debian security team a while ago and they are ok with duplicate source code as long as the updates are done in a timely manner. Tor Browser has a good record, so it's fine.
Reasons for unavailability of TBB .deb in the Tor Project APT repository:
- The break neck speed of development
A regular build could probably be automated via Jenkins.
- Its not easily packaged and the amount of effort needed is better spent
otherwise.
As far as I understand, the main issue is that Tor Browser only works with a single (pre-populated) profile which can't be shared amongst multiple users. Once this is solved, and Tor Browser can be installed system-wide, getting a package should not be very hard.
Hope that helps,
On 2016-06-10 18:27, Lunar wrote:
bancfc@openmailbox.org:
Rehash of previous discussions on the topic:
See #3994.
The major reasons why TBB is not in the Debian repository:
- The reproducible build system depends on a static binary image of
(then Ubuntu) which runs counter to Debian policy.
It's likely not a problem if built from source.
- TBB is based on Firefox ESR and not Iceweasel which also runs into
the "no duplicate source package" policy of Debian.
I've discussed this with Debian security team a while ago and they are ok with duplicate source code as long as the updates are done in a timely manner. Tor Browser has a good record, so it's fine.
Reasons for unavailability of TBB .deb in the Tor Project APT repository:
- The break neck speed of development
A regular build could probably be automated via Jenkins.
- Its not easily packaged and the amount of effort needed is better
spent otherwise.
As far as I understand, the main issue is that Tor Browser only works with a single (pre-populated) profile which can't be shared amongst multiple users. Once this is solved, and Tor Browser can be installed system-wide, getting a package should not be very hard.
Hope that helps,
Thanks Lunar for the update. I thought the effort to upstream TBB had completely stalled because there was no activity on #3994. Good to know its still alive.
Is there somewhere I could look to track progress besides that ticket?
bancfc@openmailbox.org:
Thanks Lunar for the update. I thought the effort to upstream TBB had completely stalled because there was no activity on #3994. Good to know its still alive.
Is there somewhere I could look to track progress besides that ticket?
Don't misunderstand me. To the best of my knowledge, no one is working on this at the moment. I was just sharing my picture of the situation.
-
bancfc＠openmailbox.org -
carlo von lynX -
Hans-Christoph Steiner -
Lunar -
meejah