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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
