[tor-bugs] #5236 [Tor bundles/installation]: Make a deb of the Torbrowser and add to repository

[Tor Bug Tracker & Wiki]

#5236: Make a deb of the Torbrowser and add to repository
--------------------------------------+-------------------------------------
 Reporter:  cypherpunks               |          Owner:                   
     Type:  enhancement               |         Status:  needs_information
 Priority:  normal                    |      Milestone:                   
Component:  Tor bundles/installation  |        Version:                   
 Keywords:                            |         Parent:                   
   Points:                            |   Actualpoints:                   
--------------------------------------+-------------------------------------

Comment(by micahlee):

 Replying to [comment:22 proper]:
 > gpg:
 >
 > a) Ship the gpg keys with the deb package and the packager keeps the
 keys updated? Or,
 > b) hardcode the gpg fingerprints and download it from the keyserver?
 > c) somehow magically phrase the tpo verification page

 I like a) the best. It seems simple and unlikely to break.

 > A clean solution would be:
 > #5606: "deb package with all torproject.org signing pgp keys" - but that
 requires help from tpo.
 >
 > ...or the TBB bundles get signed with the tpo archive signing keys
 instead of the individual account holders.

 https://www.torproject.org/docs/signing-keys.html.en says "Erinn Clark
 (0x63FEE659) signs the Tor Browser Bundles, Vidalia bundles, and many
 other packages."

 I think it would be fine to include Erinn's public key in the package, and
 have the downloader also download and verify the sigs (like
 https://www.torproject.org/dist/torbrowser/linux/tor-browser-gnu-linux-
 x86_64-2.3.25-2-dev-en-US.tar.gz.asc). If Erinn ever stops signing the TBB
 tarballs, we can update Tor Browser Launcher and include the new signing
 key.

 > Dependencies:
 >
 > What should the script depend on? Is curl fine? I like curl because it
 can enforce https with TLS. Is a dependency on bash ok with Debian policy?
 I'd hate caring about sh compatibility.

 I think curl is fine. I don't know about bash dependency and Debian, but I
 think it's fine to start with it and if it turns out to be an issue
 refactor bash out of it.

 The GUI stuff I've been programming depends on python-gtk2. I've never
 used zentity before, and that might be a simpler approach. I guess that's
 a design decision to make too:

 a) Do it all in python
 b) Do it all in bash and reuse much of the Whonix code
 c) Use both python and bash

 I like the idea of using python and GTK because then we can have nicer
 user interfaces. Like, a choose your language dropdown if we want it, and
 we can build more of a wizard interface for first run and upgrades.
 However, maybe zentity can do everything we need, and it might simplify
 things.

 Also, it's easier to do some logic, such as automatically determining
 which language to use, in python than bash (and that's logic that I've
 already committed to the repo).

 > Download through Tor:
 >
 > Download through Tor or clearnet? Download through Tor to allow
 obfsproxy (or similar) users to hide that they are using Tor? Download
 through Tor is a bit difficult so or so, since it would require Tor to be
 installed and another instance of Tor comes with the TBB package.
 Downloading Tor with apt-get wouldn't hide Tor anyway. I think it probable
 should download through clearnet unless someone has a better idea.

 I agree, we should download it without Tor. Maybe in the future
 downloading through Tor can be added if we come up with a good way.

 > Debian policy:
 >
 > Debian is against code duplication... So the script itself wouldn't be a
 code duplication, but the result download would result in duplicate code
 for Firefox and Tor. I personally find this policy odd and there should be
 exceptions.

 I think this project arguable doesn't count as code duplication. Or at
 least, there's a good argument that this doesn't count.

 > Progress bar:
 >
 > The script already has a zentiy progress bar, which generally works
 well. Unfortunately it stops at 50% because I didn't manage to phrase the
 curl progress bar to output usable by zenity. Can you help out here?

 I only briefly read through the script, but I should try actually running
 it and see how it looks.

 > Once this is decided I could remove the Whonix specific parts. Shouldn't
 take long.

 The other decision to make is the directory structure. Here's what I'm
 thinking:

 $HOME/.torbrowser -- all Tor Browser Launcher files live here
 $HOME/.torbrowser/version -- text file with current installed version
 $HOME/.torbrowser/download -- where tarballs get downloaded to
 $HOME/.torbrowser/tbb/ARCH/LANG -- where TBB gets extracted to

 So running, for exmaple, ~/.torbrowser/tbb/x86_64/en-US/start-tor-browser
 would launch it for me. And as long as I'm still using x86_64 and my
 language is still en-US, updates would overwrite that.

 Each time torbrowser-launcher gets run it checks it's hardcoded TBB
 version against what's in ~/.torbrowser/version to see if an update it
 required.

 Does this seem reasonable?

 And of course all the GUI stuff should be localized into all the languages
 supported by TBB as well.

 I've been spending a lot of time on this and have to get back to other
 work. If you want to clone my existing repo and make it work more with
 bash and zenity, I'll gladly merge your work back in.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5236#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online