Re: [tor-bugs] #10395 [Tor]: Tor's consensus lists Torbrowser updates

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#10395: Tor's consensus lists Torbrowser updates
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  mikeperry
  StrangeCharm           |     Status:  needs_review
         Type:           |  Milestone:  Tor: 0.2.6.x-final
  enhancement            |    Version:
     Priority:  major    |   Keywords:  pantheon chronos prop227 nickm-
    Component:  Tor      |  patch
   Resolution:           |  Parent ID:  #10393
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by gk):

 Replying to [comment:15 mcs]:
 > 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).

 Good question. Even after re-reading section 3.1 a couple of times it is
 still not easy to extract all the necessary things. I think we need to
 rethink/clarify that section at least partly (for instance, that the Tor
 Browser is dowloading the JSON file again and is using that one (How does
 it e.g. know it got the one the Tor client downloaded earlier to check
 whether the hash is correct?) seems a bit weird. At least the hash should
 be checked again. Probably the JSON file should get downloaded only once
 anyway...). But as far as I can see there are no additional tor things
 needed.

 > - 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).

 This is a good point. I am leaning to Nick's idea to even include the full
 OS/platform portion. IIRC in the past we had at least one occasion where
 we shipped only new bundles for 64 bit Linux. That was related to a
 compiler bug: #10195. If we think that's too much overhead then at least
 the OS should get added. We may want to add a Tor Browser for Android one
 day and I can imagine that these bundles are different enough that we (at
 least in the beginning) have to release bugfixes much more frequent than
 for Linux/Mac/Windows bundles.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10395#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs