Tor's consensus lists Torbrowser updates
Tor's consensus lists not only recommended versions of Torbrowser, but also the version numbers, names, and hashes of incremental updates.
Activity
changed milestone to %Tor: 0.2.6.x-final
Proposal 227 from Nick and Mike: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/227-vote-on-package-fingerprints.txt
Replying to gk:
I still like to be on Cc here. :)
Whoops; sorry. I think that was one of those concurrent-edit glitches. :/
-
Replying to nickm:
Latest version is in a branch called "prop227_v2".
I do not see that branch when I look at https://gitweb.torproject.org/nickm/tor.git/refs/heads Am I looking at the wrong repo or did you forget to push it or ?
Nick - when I initially wrote this proposal, I assumed that the full consensus was available from the control port. It looks like 'getinfo ns/all' doesn't actually give us any of the consensus headers where this field may appear.
I am wondering if it would be possible to export this 'package' field to the control port via a getinfo command, so we can extract it without having to parse the entire consensus? I suppose an event could also work.
-
Replying to mcs:
Replying to nickm:
Latest version is in a branch called "prop227_v2".
I do not see that branch when I look at https://gitweb.torproject.org/nickm/tor.git/refs/heads Am I looking at the wrong repo or did you forget to push it or ?
You are right; it appears I forgot to push it. I pushed the thing on my desktop named "prop227_v2". Hope it was right. So sorry :(
-
Replying to mikeperry:
Nick - when I initially wrote this proposal, I assumed that the full consensus was available from the control port. It looks like 'getinfo ns/all' doesn't actually give us any of the consensus headers where this field may appear.
I am wondering if it would be possible to export this 'package' field to the control port via a getinfo command, so we can extract it without having to parse the entire consensus? I suppose an event could also work.
A getinfo command would not be hard.
-
Replying to nickm:
You are right; it appears I forgot to push it. I pushed the thing on my desktop named "prop227_v2". Hope it was right. So sorry :(
No problem. Thanks for your work on this feature. Kathy and I reviewed the prop227_v2 code as best we could (we are not very familiar with the tor code, so we may have overlooked something). It looks good to us. We have just a couple of minor comments:
-
There is a typo in the comment just before validate_recommended_package_line (recommened_packages should be recommended_packages). Actually, it might be better to replace that with RecommendedPackages to match the torrc option. Also, unless it is not your practice to do so, it would be helpful to include a comment there that defines the grammar for the line.
-
In or.h, replace "pacakges" with "packages" in a comment.
We also have a couple of comments on Proposal 227 itself:
-
The consensus method, currently listed as (TBD), can be filled in with 19.
-
There is no definition for DIGESTTYPE. Or is that defined in another spec.? We are assuming that it has the same definition as DIGESTVAL.
-
-
Kathy and also want to raise some Prop 227 issues that are specific to Tor Browser's intended usage (for Mike and GK to ponder):
-
The proposal mentions a "proposed update timestamp" which is checked against the consensus timestamp. Where will that timestamp come from? It seems like it will need to be a field within the JSON document that the consensus points to, but if so, the steps described are slightly out of order (the JSON file would need to be downloaded and its hash verified against the consensus before the timestamp could be retrieved and checked).
-
If we do not include an OS/platform name in the consensus package names, then we will always need to release Tor Browser for all platforms at the same time. This might be OK, but it is worth thinking about whether we want to use one package name (e.g., tbb-stable or maybe just tb-stable) or 3 package names (e.g., tb-stable-linux, tb-stable-win, tb-stable-mac).
-
