Bug#910062: torbrowser-launcher will not open URL argument
On 10/2/18 5:59 AM, intrigeri wrote: > Indeed. Can you please check if there's already an upstream feature > request about this, and if not, create one? Thanks! A long time ago torbrowser-launcher could accept URLs as arguments, but then a change in Tor Browser itself broke that feature, so I removed it. Here is a recent pull request that tried to reimplement it, but I closed without merging after explaining the issue: https://github.com/micahflee/torbrowser-launcher/pull/274 I'm not sure if there's an upstream-upstream ticket for Tor Browser itself about this, but that would be the place to start.
Bug#888236: Fixed upstream
This bug has been fixed upstream in the torbrowser-launcher 0.2.9 release: https://github.com/micahflee/torbrowser-launcher/releases/tag/v0.2.9
Bug#860268: .desktop files can hide malware in Nautilus
Package: nautilus Version: 3.22.3-1 There is a bug in Nautilus that makes it possible to disguise a malicious script as an innocent document, like a PDF or ODT, that gets executed when the user opens it. The upstream nautilus issue [1] has already been resolved, and will be released in nautilus 3.24. But since this is an important security issue, I think this patch should be backported so that it's fixed in older versions of Debian. See this blog post [2] for more about how this bug allows attackers to compromise the security-focused Debian-based distro Subgraph. [1] https://bugzilla.gnome.org/show_bug.cgi?id=777991 [2] https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/
Bug#852732: torbrowser-launcher: sig verification failed: also for first time download
On 01/26/2017 03:23 PM, Gregor Zattler wrote: > Package: torbrowser-launcher > Version: 0.2.6-3 > Followup-For: Bug #852732 > > Dear Maintainer, > > I have the very same problem as Sebastian Niehaus with > torbrowser-launcher from debian testing while trying to download > tbb for the very first time. > > Most probably the problem is with the files on the tor projects > server but ATM there is nothing at the tor mailinglist archives about > the problem. > > Thanks, Gregor I have fixed this issue upstream and made a new release: https://github.com/micahflee/torbrowser-launcher/releases/tag/v0.2.7
Bug#793791: [Pkg-anonymity-tools] Bug#793791: torbrowser-launcher: Fail to start TypeError: _getEndpoint() takes exactly 4 arguments (2 given)
On 07/27/2015 08:11 AM, Guillaume Seren wrote:
Dear maintener,
while trying to launch torbrowser-launcher it fail,
and return me this error:
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.2.0
https://github.com/micahflee/torbrowser-launcher
Updating over Tor
Checking for update
Downloading
https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions
Traceback (most recent call last):
File /usr/bin/torbrowser-launcher, line 30, in module
torbrowser_launcher.main()
File /usr/lib/python2.7/dist-packages/torbrowser_launcher/__init__.py,
line 69, in main
app = Launcher(common, url_list)
File /usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py,
line 130, in __init__
self.build_ui()
File /usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py,
line 284, in build_ui
self.start(None)
File /usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py,
line 293, in start
self.run_task()
File /usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py,
line 310, in run_task
self.download('update check', self.common.paths['update_check_url'],
self.common.paths['update_check_file'])
File /usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py,
line 469, in download
None)
File /usr/lib/python2.7/dist-packages/twisted/web/client.py, line 1926,
in request
deferred = self._agent.request(method, uri, headers, bodyProducer)
File /usr/lib/python2.7/dist-packages/twisted/web/client.py, line 1559,
in request
endpoint = self._getEndpoint(parsedURI)
TypeError: _getEndpoint() takes exactly 4 arguments (2 given)
Guillaume.
I can reproduce. By default torbrowser-launcher tries to update over
Tor. A workaround is running torbrowser-launcher --settings and
disabling updating over Tor, and then it works fine.
I'm not sure exactly the cause, but it appears to be a bug in
python-twisted-web. Scrapy has run into the same issue [1] and they
resolved it with this commit [2], although it's not clear how to apply
that same fix to torbrowser-launcher.
I just opened an upstream bug [3].
[1] https://github.com/scrapy/scrapy/issues/1034
[2]
https://github.com/scrapy/scrapy/commit/d67ca77e61020802c593c8b60a977e26bebfd7c6
[3] https://github.com/micahflee/torbrowser-launcher/issues/192
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763739: torbrowser-launcher: Settings GUI - Launch button does not work
On 10/02/2014 09:37 AM, u wrote: When i launch torbrowser-launcher -settings and then click on Launch now i get a permission error. Starting settings dialog Traceback (most recent call last): File /usr/bin/torbrowser-launcher, line 506, in save_launch subprocess.Popen([self.common.paths['tbl_bin']]) File /usr/lib/python2.7/subprocess.py, line 679, in __init__ errread, errwrite) File /usr/lib/python2.7/subprocess.py, line 1259, in _execute_child raise child_exception OSError: [Errno 13] Permission Denied I released a new version of torbrowser-launcher upstream on Monday that should have fixed that problem: https://github.com/micahflee/torbrowser-launcher/commit/876eb0bdc3dbf6fcfed2ecc8a246a53305ac61ed -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762890: [Pkg-anonymity-tools] Bug#762890: Bug#762890: Bug#762890: Proposal for next release
On 09/29/2014 01:08 PM, u wrote: intrigeri wrote: This refactoring would also help a lot integrating onionshare properly into Tails and Whonix (how this can be combined with their filtering Tor control protocol proxies is left to be thought). Sounds like the way to go :) I've started to spec this out here: https://github.com/micahflee/onionshare/issues/153 Feedback (and help implementing) is more than welcome. But yeah, I don't think this can be complete in time for Jessie. -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762890: [Pkg-anonymity-tools] Bug#762890: onionshare: use the default Tor control settings
On 09/26/2014 12:06 AM, Paul Wise wrote: OnionShare should use the default control settings for the Debian tor: Unfortunately OnionShare doesn't work with the system tor without changing a bunch of stuff around, due to limitations in tor. Instead it's recommended that you install Tor Browser Bundle (perhaps using the torbrowser-launcher Debian package) and run it before running OnionShare. When you connect to the control port, you start a hidden service by setting the values HiddenServiceDir and HiddenServicePort. The control port doesn't respond with the .onion address, which is an important thing to know. The only way to learn that is to look in HiddenServiceDir for a file called hostname and read its contents. If you're using a system tor, that file is only readable by the debian-tor user, which means an unprivileged user can't learn the .onion address. Also (at least I believe) in the default Debian torrc file the control port isn't enabled. So users would have to edit their torrc before being able to use OnionShare. If the user has Tor Browser open, it will be running its own separate Tor process as the current user. So when it writes a hostname file to HiddenServiceDir, that file is readable by the current user. One potential option to help this problem would be to make tor a dependency of onionshare, and have OnionShare launch its own tor process (independent of the system tor process) for starting a hidden service. -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760308: onionshare uses http only and thus should not be released with jessie
All Tor hidden services (any website that's accessed through a .onion domain) are automatically end-to-end encrypted. In the case of OnionShare, the crypto key lives in /tmp/onionshare_XXX/private_key. The .onion URL address itself is a fingerprint of the key, which lets the Tor network look up the public key and start an encrypted session. So as long as you transmit the OnionShare URL successfully, the recipient who loads it in Tor Browser gets an end-to-end encrypted session with the server. Using HTTPS on top of this could be an option too actually, but the certificates would all have to be self-signed so users would have to click through the error. And the encryption would be redundant (though not necessarily a bad idea -- defense in depth, in case Tor gets badly broken in ways we can't foresee or something). -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757627: [Pkg-anonymity-tools] Bug#757627: Bug#757627: Download error: Download Error: 404 Not Found class '__main__.DownloadErrorException'
On 08/10/2014 06:30 AM, intrigeri wrote: https://lists.torproject.org/pipermail/tor-qa/2014-August/000439.html (Maybe some of the torbrowser-launcher package maintainers should read that low-volume list?) Good idea, I'll subscribe. The main upstream bug is at [1]. But there are a couple things going on here. The format of the RecommendedTBBVersions file [2] keeps changing (upstream bug [3]). It was only listing stable releases for a long time, and then with this next release it started listing alphas again. And TBL has been checking TBB releases against Mike Perry's key using the file sha256sums.txt-mikeperry.asc, but the new releases don't have that file, only sha256sums.txt.asc and Erinn Clark's key. Which means that debian bug [4] and upstream bug [5] look like they're not possible, until we get clarity from the Tor devs. I'm preparing an upstream release to fix this. But I'm also at an airport and my plane is already boarding, so if there isn't wifi on the plane I might not be able to get to it until late tonight. [1] https://github.com/micahflee/torbrowser-launcher/issues/120 [2] https://check.torproject.org/RecommendedTBBVersions [3] https://github.com/micahflee/torbrowser-launcher/issues/63 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756194 [5] https://github.com/micahflee/torbrowser-launcher/issues/113 -- Micah Lee signature.asc Description: OpenPGP digital signature
Bug#754281: v0.1.2 detaches and hides all output
Actually the only reason I made it detach and hide output in this release was because not detaching had a small annoying issue related to the optional playing a modem sound feature. It shouldn't be too hard to fix though. On 08/02/2014 03:32 PM, Holger Levsen wrote: Hi, the subject basically says it. I'll probably file a wishlist bug to get an option to not detach itself and to actually output all the output again. cheers, Holger -- Micah Lee signature.asc Description: OpenPGP digital signature
Bug#756194: [Pkg-anonymity-tools] Bug#756194: should verify 3 signatures are correct
Are you sure that the releases always have 3 signatures? My worry would be that maybe one of the devs isn't available and they do a release with only 2 signatures, and Tor Browser Launcher users won't be able to update. On 08/02/2014 03:21 PM, Holger Levsen wrote: control: forwarded -1 https://github.com/micahflee/torbrowser-launcher/issues/113 Hi, On Sonntag, 27. Juli 2014, Holger Levsen wrote: tbb downloads are signed by 3 signatures always, all three of them should be checked and if there are not 3 valid signatures (or an invalid one), it should fail and warn loudly. this is being tracked as an upstream feature request now too. cheers, Holger -- Micah Lee signature.asc Description: OpenPGP digital signature
Bug#755684: torbrowser-launcher: cannot launch the Tor Browser
On 07/30/2014 09:00 PM, Paul Wise wrote: The bug has already been closed as torbrowser-launcher works now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755684#61 In jessie it's still broken for me. With everything updated, this is what happens when I run torbrowser-launcher: micah@debian:~$ rm -rf .torbrowser/ micah@debian:~$ torbrowser-launcher /usr/lib/python2.7/dist-packages/twisted/internet/_sslverify.py:184: UserWarning: You do not have the service_identity module installed. Please install it from https://pypi.python.org/pypi/service_identity. Without the service_identity module and a recent enough pyOpenSSL tosupport it, Twisted can perform only rudimentary TLS client hostnameverification. Many valid certificate/hostname mappings may be rejected. verifyHostname, VerificationError = _selectVerifyImplementation() Tor Browser Launcher By Micah Lee, licensed under GPLv3 version 0.1.0 https://github.com/micahflee/torbrowser-launcher Initializing Tor Browser Launcher Warning: can't load mirrors from /usr/local/share/torbrowser-launcher/mirrors.txt Creating GnuPG homedir /home/micah/.torbrowser/gnupg_homedir Importing keys gpg: keyring `/home/micah/.torbrowser/gnupg_homedir/secring.gpg' created gpg: keyring `/home/micah/.torbrowser/gnupg_homedir/pubring.gpg' created gpg: /home/micah/.torbrowser/gnupg_homedir/trustdb.gpg: trustdb created gpg: key 63FEE659: public key Erinn Clark er...@torproject.org imported gpg: key C5AA446D: public key Sebastian Hahn m...@sebastianhahn.net imported gpg: key 4279F297: public key Alexandre Allaire alexandre.alla...@mail.mcgill.ca imported gpg: key 683686CC: public key Mike Perry (Regular use key) mikepe...@torproject.org imported gpg: Total number processed: 4 gpg: imported: 4 (RSA: 4) gpg: no ultimately trusted keys found Starting launcher dialog Checking for update Running task: download_update_check Downloading https://check.torproject.org/RecommendedTBBVersions Download error: [twisted.python.failure.Failure class 'twisted.internet._sslverify.SimpleVerificationError'] class 'twisted.web._newclient.ResponseNeverReceived' Running task: attempt_update Checking to see if update is needed -- Micah Lee signature.asc Description: OpenPGP digital signature
Bug#755684: torbrowser-launcher: cannot launch the Tor Browser
On 07/31/2014 11:37 AM, Holger Levsen wrote: that bug is not yet fixed in jessie yet, the fixed package will migrate tomorrow. or did you use the package from sid on jessie? Oh alright, good to hear. I used the package from jessie, not sid. I'll try again tomorrow. -- Micah Lee signature.asc Description: OpenPGP digital signature
Bug#755684: torbrowser-launcher: cannot launch the Tor Browser
I've created an upstream bug: https://github.com/micahflee/torbrowser-launcher/issues/116 I just installed sid in a VM and installed the torbrowser-launcher package, and it runs fine without this problem. So this appears to be a Debian packaging issue then that will be resolved when certain packages make their way from sid into jessie, right? Is there anything I can do to help fix it on my end? -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752275: torbrowser-launcher: several possible/probably security issues
Rather than replying in-line to everything, I'll just summarise: * TLS/x.509 security: torbrowser-launcher doesn't rely on the CA infrastructure. The only TLS it does is make HTTPS requests to check.torproject.org and (if you haven't set a mirror) www.torproject.org. When it connects to these hostnames, it uses a hardcoded certificate. So none of the TLS PKI issues apply at all here. (And I took extra measures to make sure the .pem included with torbrowser-launcher is valid. I downloaded the cert from several different internet connections/ISPs and compared, and when I had one I thought was correct I sought out Tor devs to verify I was including the right one and not a malicious one.) * Downgrade attacks shouldn't be possible, unless they're committed by Tor devs themselves. If an attacker captures a valid old request to https://check.torproject.org/RecommendedTBBVersions that claims that the current version is an older version than what's currently installed, torbrowser-launcher prevents it from installing. (And by installing I mean extracting to the user's home dir.) However, there is the scenereo where the user has set a third-party mirror to download from instead of the default. The third-party mirror could serve a tarball and sig that have filenames of the latest version, but are actually an older version. This attack is mitigated by the fact that all mirror options use HTTPS -- though none of the mirror certs are pinned, so in this case it would rely on CA infrastructure. This is an edge case, and would only work against users who are using a non-default mirror, and who also have access to a trusted CA signing key. * You cannot install Tor Browser system-wide. It's released by the Tor Project as a bundle. There's a lot of code in there that specifically prevents it from touching any other files outside of it's own directory. All files need to be owned by current user, and it's designed to be runnable off of a USB stick. A long time ago I put a bunch of work into tearing apart the bundle-ness of TBB to make it installable systemwide, and concluded it wasn't practical without the Tor devs releasing it as such. If you could install it systemwide, there would be no reason for torbrowser-launcher -- it could then just be a normal debian package. * Yes, attackers that 1) have access to the trusted keys included with torbrowser-launcher and 2) have access to modify files on https://www.torproject.org/ or have access to its TLS key are able to get arbitrary code exec as the current user when they open Tor Browser. This may or may not include any of the Tor devs whose keys are included. But like Holger said above, this is a feature, not a bug. This is the whole purpose of torbrowser-launcher, so users can automatically install TBB updates that are signed by Tor devs. -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752275: torbrowser-launcher: several possible/probably security issues
are expliticly checked for, and will fail with an error message saying: Something is wrong. The version of Tor Browser Bundle you have installed is newer than the current version? See: https://github.com/micahflee/torbrowser-launcher/blob/master/torbrowser-launcher#L629 Since thes are signed with valid keys (but AFIACS with no valid from/through information) the downloader will just happily accept them. I'm not sure, but I guess it doesn't help if you download things via https. Another issue are blocking attacks... when no connection can be made at all to the tor download servers, will it start the currently downloaded version of the bundle or will it simply fail? In case it doesn't fail, it could again be used to trick people into using software with known security deficiencies. It simply fails. An attacker that can block access to https://check.torproject.org/ can prevent torbrowser-launcher from launching the browser. The settings do letter people try using different mirrors, however, so if https://www.torproject.org/ is blocked they can still download a new version, and it will still have its signature verified. Such downloader packages are quite danerous per se,... as it's very tricky to really securely do it. Usually the best way is to hard code a secure hash (i.e. not MD5) of the upstream package which is currently considered secure... every time a new upstream version comes out, a new downloader package should come out as well with a new hash,...so that people regularly (via the package management system) notice about [security] updates. I considered this at first, but new versions of TBB come out so frequently that this would be quite a lot of work to maintain. I also doubt that it would be as secure. There would be a window of time when Tor Project releases an updated TBB where torbrowser-bundle users won't be able to download the latest version because the update is working its way through the Debian pipeline. Cheers, Chris. btw: Apart from that... I've always wondered how secure something like torbrowser bundle can be... per se, they will always lag a bit behind FF with security updates,... and FF in turn already has enough security issues. The Tor devs seem to be very much on top of this. I don't think TBB lags behind more than 24 hours when there are Firefox security bugs that affect it. btw2: Since torbrowser-launcher is probably usually launched as normal user, I marked this as user security hole only. But given that torbrowser-launcher will typically be run on desktops/notebooks... successfully attacking that user is usually equivalent to root exploit (the attacker could simply wait for the user to sudo/su to root and keylog his password). So actually severity is IMHO critical. I think in order to successfully attack torbrowser-launcher to run arbitrary code as the desktop user you would need: 1) One of the Tor dev signing keys that's included 2) The secret SSL key for https://www.torproject.org/ (unless the user is using a mirror) 3) Either be in a position to MITM the user, or have owned Tor's web server To do this same attack against a normally Debian system you only need: 1) The Debian repository signing key 2) Either be in a position to MITM the user, or have owned the repo's web server I agree that having Tor Browser proper, directly from the Tor project, in Debian would be better than using torbrowser-launcher. But unfortunately this is a massive undertaking that would involve doing some wonky things (like adding an iceweasel-src package to the binary repo, so that Tor Browser could apply its extra Firefox patches). In the end, torbrowser-launcher turns out to be by far the most elegant solution. Here's the bug: https://trac.torproject.org/projects/tor/ticket/3994 Without torbrowser-launcher, when Debian users want to use Tor Browser they'll visit https://www.torproject.org/ and download it. Most users probably won't verify the gpg signature, and they'll just trust the CA system that their download wasn't attacked. They'll have to open a terminal and manually run the start-tor-browser script because there's no application launcher. There also won't be any auto-updating, so when they're browser is out of date they'll either just use an insecure version of Tor Browser, or they'll repeat the same steps to download and install it again without verifying the signature or pinning the torproject.org cert. Of course, it's possible for Debian users to manually do all of the things that torbrowser-launcher automatically does, assuming they already know exactly which cert torproject.org uses, and assuming they have the correct TBB signing key (both things that are difficult to get right if you're under an active CA attack, and aren't connected to the Tor dev's keys in the web of trust, or don't know what the web of trust is). -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble
Bug#751453: (no subject)
FYI, I've opened an upstream bug to fix the AppArmor profiles: https://github.com/micahflee/torbrowser-launcher/issues/92 -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
