Re: [tor-dev] Tor Browser Launcher

[Jacob Appelbaum <jacob@xxxxxxxxxxxxx>]

Micah Lee:
> On 02/18/2013 12:29 PM, Jacob Appelbaum wrote:
>>> I was assuming that making the launcher depend on a system Tor would be
>>> troublesome. However now that I'm looking at
>>> https://www.torproject.org/docs/debian again, it seems like it could
>>> totally work. What about for Ubuntu users?
>>
>> For normal Debian GNU/Linux users, I believe it will work. For recent
>> versions of Ubuntu, I also believe it will work. I would also say that
>> the launcher could prompt them to actually *add* the Tor repositories
>> that fix the problems Ubuntu users may or may not face in the future.
> 
> True. I'll start with just a normal Tor dependency, and if only add the
> deb.torproject.org repo if it becomes necessary.
> 

That seems fine as a start.

>>> My workaround plan was to download TBB not over Tor the first time.
>>> After extracting it, copy a Firefox extension into the TBB profile, and
>>> then run it. From that point on, the extension would be in charge of
>>> checking for updates, downloading new updates, and telling the user when
>>> they should restart their browser.
>>>
>>
>> I'm not sure I follow? You want to extend TBB to check for updates
>> itself? In the long term, I think that is a fine plan - though in the
>> short term, I think a simple script can be safer, easier and generally
>> better. Imagine for a moment that there was a system wide cache of TBB
>> downloads? One TBB to rule them all, or something. Such a thing wouldn't
>> be easy inside of Firefox.
> 
> My plan was to make the Firefox extension, and then after extracting the
> TBB tarball copying the extension into
> ~/.torbrowser/tbb/x86_64/tor-browser_en-US/Data/profile/extensions and
> doing whatever you need to do to enable it that profile. However, since
> I'm going to make Tor a dependency, it's moot.
> 

I think a Firefox extension is a fine idea generally but specifically,
an out of TBB solution seems most expedient.

>>> What do you think the report button should do? What information should
>>> it send back to us, and how should it send it? If there is a real attack
>>> and the user can't successfully download TBB, how can we make sure they
>>> can successfully report the attack? You can post comments on the bug.
>>>
>>
>> I'll add comments to the bug.
> 
> Thanks!
> 
>>>> Do you pin SSL certs? Or fetch from known mirrors? Or...? :)
>>>
>>> No. I assumed that if someone successfully did a MITM attack on the
>>> https connection to torproject.org, they wouldn't get their malicious
>>> software installed because of the signature verification. Also, I didn't
>>> realize urllib2 doesn't check certs automatically. It's a good idea to
>>> implement anyway. Thanks for opening the bug about it.
>>>
>>> https://github.com/micahflee/torbrowser-launcher/issues/1
>>>
>>
>> Sure - I find it hard to believe that Python's development community
>> actually settled on that as the default behavior. It bites nearly everyone.
> 
> Python's development community also doesn't verifying anything
> downloaded by pip:
> http://www.reddit.com/r/Python/comments/17rfh7/warning_dont_use_pip_in_an_untrusted_network_a/
> 
> Hopefully it will get better soon.
> 

Yeah, I'm unimpressed to say the least. I know it has been that way for
a while. I'm pretty amazed that someone hasn't just tossed up an SSL
mirror with some look-aside code.

>>> I'd thought about this, but I wasn't sure if this is a reliable way to
>>> know which version to download. For example, when I go to
>>> https://www.torproject.org/dist/torbrowser/linux/?C=M;O=D now, the first
>>> file is:
>>>
>>> tor-browser-gnu-linux-x86_64-2.4.10-alpha-1-dev-en-US.tar.gz.asc
>>>
>>> But when I go to the TBB download page, the version I'm presented with
>>> is 2.3.25-2, not 2.4.10-alpha-1. Maybe TBB's built-in version check will
>>> shed some light onto the best way to know what the latest stable version is.
>>>
>>
>> Well, which should your users be using? From my perspective, I think you
>> should give them the alpha and help them report bugs! :-)
> 
> Interesting idea. Anyone else have opinions on this? I think I'd be fine
> giving people the alpha, but I also don't want to annoy people with too
> many bugs.
> 

I don't think there are too many bugs - I use the alpha all the time and
it seems fine.

> Right now it would be easiest to just make it get the alpha.
> 
> Or, alternatively, I could download
> https://www.torproject.org/download/download.html.en and parse it for
> the current version. However, this will break as soon as torproject.org
> updates it's web design.
> 

Well, we have wml files as well - so you can just look at those rather
than the published site.

>> I pushed a code audit first pass to the git repo, did you see the
>> branches that I added?
> 
> Yup. I merged in your doc-formatting, gpg-keys, and image-fixups
> branches into my develop branch.

Cool, thanks!

> 
> https://github.com/micahflee/torbrowser-launcher/tree/develop
> 
> And I opened issues for most of things you brought up in the code review
> branch: https://github.com/micahflee/torbrowser-launcher/issues
> 

Great - I'll comment on each respective bug.

> For the things I didn't open issues on, here are my thoughts:
> 
> https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a697216bbab3ac6eb5d20090#L0R46
> 
> I think it's safe to overwrite whatever is in the version file here,
> since TBB isn't installed yet. Unless someone messed with their
> ~/.torbrowser/ folder, it shouldn't exist yet. The version file is
> supposed to represent the currently installed version, but I think I
> might refactor this stuff anyway since I'm going to make it check for
> updates rather than hard-coding the latest version.
> 

Are you sure that it is always ~/.torbrowser/ though? :)

> https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a697216bbab3ac6eb5d20090#L0R64
> 
> I'm not sure if arch is portable. I could easily switch it to uname -m,
> if that's more portable.

My guess is that uname -m is more portable; though I bet that os.uname
or sys.platform in Python would be the most portable.

> 
> https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a697216bbab3ac6eb5d20090#L0R82
> 
> If HOME isn't set, what should happen? Should tbb_data be set to
> /tmp/tbb-USER or something?
> 

Well, I think that is an interesting question too. Are we sure that if
HOME is set that we want to write to the disk? If so, I guess we should
make a directory with mktemp or a similar Python call.

> https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a697216bbab3ac6eb5d20090#L0R82
> 
> Yeah, we should depend on tar I think.
> 

I'd suggest libtarfile rather than tar - it is written in pure Python.

> Originally I wasn't thinking of releasing this for OS X, since I was
> thinking it would know about updated versions of TBB when
> torbrowser-launcher gets updated from the deb repositories. But now it
> seems plausible to make this cross-platform. However, Windows TBB
> releases are .exe, which wouldn't work with this.

I wrote the original .exe for a different use case and while I generally
agree with you - I don't think there is any reason that we can't make
native win32 UX that matches the flow of this gtk app.

> 
> Maybe this should be GNU/Linux only at first, and future releases could
> be for OS X and Windows.
> 

I think that is a fine idea - though I suggest pure Python like things
to make it portable between GNU/Linux and *BSD from the start.

All the best,
Jake
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev