tbb-dev July 2017

tbb-dev@lists.torproject.org

12 participants
12 discussions

Re: [tbb-dev] [tor-dev] RFC: porting torbrowser (was: Re: GNU Guix and Tor Browser Packaging)
by ng0 09 Mar '18

09 Mar '18

Hi, It seems as if tbb-dev(a)lists.torproject.org is the list which would be more appropriate. If the 7 days without a reaction are simply due to the holidays in some countries, it's my mistake. If you need internal discussion about this to respond appropriately, let me know that you are reviewing this message at all. I have no expectation for "neoliberal optimized" reply times. Thanks. ng0 transcribed 7.9K bytes: > Hi folks, > > as your trademarks team / person suggested to me I get in touch with the > dev team of torproject. While I'm more involved in GNUnet, I work at the > intersection of projects. Currently this means I'm involved in system > integration. At Guix we are interested in working closer with projects > like tor, TAILS, Whonix and the like. Porting torbrowser is not only in > the interest of the Guix community but also in the interest of Wonix who > recently expressed interest in selectively using Guix for their work. > For me as maintainer of the system (in development) pragmaOS it also > means that we can decide between icecat OR torless torbrowser for > proxied GNUnet connections. > > I'm interested in your response to the actions listed below and wether > you think this will still qualify as torbrowser or what other option you > propose for us at Guix to use. "Option" here means that I am not sure > what other graphical theme you have for versions of the browser which do > not use the trademark when they can (logically) also not use the firefox > trademarks. > I would reflect in the description of the package that it is not > torbrowser but a reconstruction of the way torbrowser is build, tracking > upstream as closely as possible while removing (list of features which > were removed goes here). > This can be compared to what the inoffical Gentoo maintainer does in the > .ebuild file here: > https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ > > My request here is just in the position as a contributor to Guix, not > for pragmatique (the project which works on pragmaOS etc), Whonix, > GNUnet or any other project I mentioned before. > > Thanks in advance. Now the content I've been talking about: > > It looks like the changes I need to make to torbrowser are not so > grave at all. Someone pointed me to the gnu-linux-libre(a)nongnu.org list > to reach out to other FSDG systems. > The thread can be reviewed here: > https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html > > Basically: > > I will need to discourage Mozilla leftovers: > - the mozilla addon service will be overwritten, in other words: > Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" > it will be replaced by the thing Icecat points to. Longterm plan is > to offer firefox extensions native through "guix package -i > youraddonnamehere". > > Privacy / Tracking reasons: > - Firefox "Sync" will be disabled. > - Google will be removed from the search plugins if I understood the > procedure correctly (at least it is not in Icecat) > > A question directly for torbrowser team: > - about:license does not list licenses the torbrowser project uses, only > firefox. Why? > > DRM > - Luke from parabola mentioned that drm has been enabled in recent > versions of torbrowser. This needs to be removed aswell. > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 > https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/fire… > > ng0 transcribed 3.4K bytes: > > bancfc(a)openmailbox.org transcribed 1.9K bytes: > > > There is a serious Tor Browser packaging effort [3][4] being done by ng0 > > > (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports > > > > Eh, now that the cat is out of the bag (cat's don't belong into bags > > anyway), I think I have to do this now and not on my own conditions. > > > > Hi! > > > > As I told bancfc somewhere else, I've had a short contact with the > > trademarks team of torproject. I will get back to you when someone was > > able to identify issues in torbrowser which might lead to modifications > > of torbrowser (for more details I just hope trademarks(a)tp.o can > > communicate it to you) because all packaged software which is included > > in upstream of Guix (master) must follow the GNU Free System > > Distribution Guidelines. > > I hope that I have to make as little modifications as possible as I > > I am aware that the fingerprint of the browser could change depending on > > the kind of changes. > > > > I hope to get back to this task in about 3 weeks, right now I'm busy > > with getting more documentation done for another project. > > > > > transactional upgrades and roll-backs, unprivileged package management, > > > per-user profiles and most importantly reproducible builds. I have checked > > > with Guix's upstream and they are working on making a binary mirror > > > available over a Tor Hidden Service. [2] Also planned is resilience [2] to > > > the attack outlined in the TUF threat model. [1] > > > > > > Back to the topic of Tor Browser packaging. While there are good reasons for > > > Debian's pakaging policies they make packaging of fast evolving software > > > (and especially with TBB's reliance on a opaque binary VM for builds) > > > impractial. Both we and Micah have been doing a good effort to automate > > > downloading and validating TBB but I still believe its a maintenance burden > > > and Guix may be a way out of that for Linux distros in general. > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > *** > > > > > > [0] https://www.gnu.org/software/guix/ > > > [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md > > > [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html > > > [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html > > > [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > PGP and more: https://people.pragmatique.xyz/ng0/ > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PGP and more: https://people.pragmatique.xyz/ng0/

4 8

MacOS DMGs result in "no mountable file system" error message
by Jörg Hartmann 10 Aug '17

10 Aug '17

Hi, on my MacOS 10.12.5, both the stable 7.0.2 and the unstable 7.5a1 of the Tor Browser Bunde's DMG files, unlike all other (non-Tor) DMG files I come across, can't be mounted by the system's own DiskImageMounter. Trying to do so gives a "no mountable file system" error message. When extracting the included TorBrowser.app with BetterZip, the resulting file can't be run. Cheers, J.

2 1

Ticket #19479 closed
by Bob Ham 30 Jul '17

30 Jul '17

Hi all, I've closed ticket #19479 as this bug has already been fixed by another ticket, #16337. An explanation is in the ticket comments: https://trac.torproject.org/projects/tor/ticket/19479#comment:9 Regards, Bob

1 0

nsIUserInfo (browser developer candidate)
by Richard Pospesel 21 Jul '17

21 Jul '17

Hi tor devs! I've spent today getting ramped up on building/debugging tor-browser and investigating a solution to issue #13398 <https://trac.torproject.org/projects/tor/ticket/13398> (NsUserInfo object scrapes user's name, username, email, and domain). My first instinct was to just completely remove the offending code and interface. It looks like some things have changed in this area since the issue was filed, as this information is no longer cached on firefox startup, but is still accessible via Add-Ons through the userinfo object ( https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ Reference/Interface/nsIUserInfo ). So my question to you is in this case, do we prefer to completely excise the nsIUserInfo interface from the codebase (and break any user Add-Ons which use it) or do we prefer to replace all the per-system implementations with a single 'mock' implementation which returns empty string (or errors) for each property getter? Having read the design-doc (particularly the parts on finger printing) it seems like ripping out the class entirely is a bad idea as it would immediately identify the browser as a modern Tor Browser (given how old the API is and that vanilla Firefox still has it) and potentially break Add-Ons using it. However, simply returning empty-string for these properties would also identify the browser as Tor Browser. I know for certain that on windows the username (at least) will always return *something* so getting empty string here would also point to Tor Browser. All that said, I suspect either of the above solutions are preferable to leaking user identifying information. What do you think? best, -Richard

2 4

Ticket 21830
by Neill Miller 21 Jul '17

21 Jul '17

Hello, I have proposed a solution to this ticket: https://trac.torproject.org/projects/tor/ticket/21830 This issue is more involved than it seems, as there are a number of places that the nsTransferable is initialized and used without a loadContext, and it's not clear that the information required can always be passed along with it (e.g. when Invoked via the JS DOM path). That said, I think my proposal is better than what's there now, and am open to feedback/criticism of this method, as there may be configurations I'm not aware of (since I've only looked at this code for a couple days now). Please advise. Thanks, -Neill.

2 1

Tag: sandboxed-tor-browser-0.0.11
by Yawning Angel 18 Jul '17

18 Jul '17

Hello, Release early, release often and whatnot. As it is unlikely that I will have much time to work on this before the next alpha[0], I will tag 0.0.11 now. Changes in version 0.0.11 - 2017-07-18: * Bug 22910: Deprecate the volatile extension dir option. * Bug 22932: Add experimental Amensiac Profile Directory support. As of this release `about:addons`'s get addon pane is no longer supported at all, reflecting the (unrelased) change made to Tor Browser. As an additional defense in depth measure, addons inside the profile directory are explicitly and individually read-only bind mounted into the container, and even installing addons manually by copying the XPI into the profiles.default/extensions subdirectory will not work without altering the container setup and recompiling the sandbox. Note that the mechanism for whitelisting addons is somewhat more fragile than I would like, and in an ideal world, the Tor Browser addons would both be stored in `browser/extensions`, and cryptographically signed with a Tor Browser specific signing key. But it's an imperfect world, and in a perfect one, I'd be dealing with chromium instead[1]. The Amnesiac Profile Directory feature behaves basically as one would expect. At launch time the profile directory is copied into a tmpfs mount inside the container, so all changes made to the profile are non-persistent. The option is hidden under the `--advanced` command line flag, because it's experimental and I don't want to deal with people asking why the browser ate their preferences/bookmarks. The emphasis is on "Profile Directory", any files in the Downloads/Desktop directories inside the container are left as is, because I couldn't think of a sensible way to handle that, and a browser that can't be effectively used for downloads is rather worthless. No special handling "the user ran the update with the setting enabled". Odd/undesirable behavior may happen, so don't do that. The UI option to enable the setting is clearly marked as "Experimental" for a reason. Regards, -- Yawning Angel [0]: I reserve the right to totally flip out over more hideous evil in Firefox, if such things should come to light. [1]: I am being somewhat facetious here, and I am well aware of why this isn't the case. But since I just had to add code to deal with defanging "telemetery"...

1 0

get-tb-version broken
by Colin Childs 17 Jul '17

17 Jul '17

Hi everyone, Currently the Tor Browser user manual relies on the get-tb-version[1] script to build. This script broke some number of weeks ago, so I'm now looking into stripping that functionality from the manual. Before I go ahead and remove the functionality, I'd like to confirm that this script is no longer maintained? Thanks! [1]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/g… -- Colin Childs Tor Project https://www.torproject.org Twitter: @Phoul

2 3

Tag: sandboxed-tor-browser-0.0.10
by Yawning Angel 12 Jul '17

12 Jul '17

Hello, New tag, because "Firefox loads Google Analytics in an IFRAME as part of an 'about:' URL" is all sorts of unacceptable. The approach I went with is to reject all network access to `discovery.addons.mozilla.org` unless the user has explicitly enabled the option labeled `Modifiable Extensions (UNSAFE: Security, Anonymity)`, in which case the pane will function normally. The SelfRando workaround should be unneeded as of the next Tor Browser Alpha release as upstream fixed the underlying issue. Changes in version 0.0.10 - 2017-07-12: * Bug 22829: Remove default obfs4 bridge riemann. * Bug 22853: Something in SelfRando is totally brain damaged. * Bug 22899: `about:addons`'s "Get Addons" pane is unsafe and should be treated as such. * Bug 22901: Clarify/expand on the warnings for all the config settings. Regards, -- Yawning Angel

1 0

Using a more recent macOS SDK
by David Fifield 06 Jul '17

06 Jul '17

Most of the mac gitian descriptors are using MacOSX10.7.sdk.tar.gz. I don't know the source of that originally. In working on the mac build for Snowflake, I had to apply a few workarounds for features that are not present in the 10.7 SDK, which would be unnecessary if using the 10.9 SDK. https://bugs.torproject.org/19001#comment:32 The blog announcement for Tor Browser 7.0 notes that it drops support for macOS 10.7 and now requires 10.9. https://bugs.torproject.org/18530 Does that mean that the Firefox build uses the 10.9 SDK, while the other descriptors still use the 10.7 SDK? (It wasn't clear to me reading the source code. mac/gitian-firefox.yml unpacks MacOSX10.7.sdk.tar.gz but doesn't seem to use it.) What does it take to use a more recent SDK in other descriptors (especially mac/gitian-webrtc.yml)?

2 2

Fwd: Changes to how protocol handlers work with the LOAD_REPLACE flag
by Tom . 05 Jul '17

05 Jul '17

May be relevant ---------- Forwarded message ---------- From: Honza Bambas <hbambas(a)mozilla.com> Date: 5 July 2017 at 06:16 Subject: Changes to how protocol handlers work with the LOAD_REPLACE flag To: "dev-platform(a)lists.mozilla.org" <dev-platform(a)lists.mozilla.org>, Firefox Dev <firefox-dev(a)mozilla.org> tl;dr: protocol handlers no longer set the LOAD_REPLACE flag, instead set loadInfo.resultPrincipalURI to channel.URI to change the address bar displayed URL. More details in bug 1319111 [1]. In a bit more details - state BEFORE: - The URL used for the result principal of the document (and shown in the address bar) was channel.originalURI, unless LOAD_REPLACE was set. Then it was channel.URI. Protocol handlers that wanted to affect this URL needed to set channel.URI appropriately and set the LOAD_REPLACE flag. - If a protocol handler was delegating to another ("inner") protocol handler and wanted to revert the URI override, it removed the LOAD_REPLACE flag from the resulting channel. State AFTER: - To have a URL other than channel.originalURI show in the address bar and get used for the channel principal, a protocol handler sets loadInfo.resultPrincipalURI to that URL. - If a protocol handler is delegating to another ("inner") protocol handler and wants to revert the URI override, it must save loadInfo.resultPrincipalURI before and then restore it after the "inner" protocol handler created the result channel. - During HTTP redirects, if the target protocol handler does not set loadInfo.resultPrincipalURI to a non-null value while creating the channel, it will be set to the redirect target URI. What has NOT CHANGED: - LOAD_REPLACE is still set on channels that have been redirected by a 30X HTTP response from a server or have been internally redirected (subject to change in a followup bug) or are part of a multi-part content. - originalURI of an HTTP-redirected channel is changed to the first URL in the whole redirect chain AFTER all redirect veto checks finished. - channel.originalURI is used for the address bar and security checks by default when loadInfo.resultPrincipalURI is is left null (similarly to as when LOAD_REPLACE flag was not set). -hb- [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1319111 PS: Many thanks to Boris Zbarsky for his great help with this effort :) _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev July 2017