Greg's browserfeedwriter javascript finds TBB's full path on Windows

http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html

Shondoit went there using TBB on Windows and it said "found location: "file:///[...]/Tor%20Browser/FirefoxPortable/App/Firefox/components/FeedWriter.js" where [...] is his install location.

Reported at https://blog.torproject.org/blog/new-tor-browser-bundles-17#comment-15627

added component::applications/tor bundles/installation owner::Sebastian priority::very high resolution::fixed status::closed tbb-fingerprinting type::defect labels

Trac:
Cc: N/A to erinn, Sebastian

Trac:
Cc: erinn, Sebastian to erinn, Sebastian, g.koppen@jondos.de

FYI: For whatever reason, Mac and Linux use resource urls in JS exceptions, not filesystem paths. Pretty sure this was a huge concern for Mozilla back in the Firefox 2.0 days, and it got fixed everywhere.. Or at least, so we thought. Not sure what the hell is up with Windows.. If it was always broken, or if someone snuck in a helpful new "debugging feature" into Rapid Release at some point.

Am currently digging around for things that implement nsIException to try to find the culprit. I'll see if I can find the mercurial blame logs, too.

Trac:
Component: TorBrowserButton to Firefox Patch Issues
Priority: major to critical
Keywords: N/A deleted, tbb-linkabilility added

Classes that implement nsIException: nsBaseDOMException, nsXPCException, nsException.

The particular error Greg generates appears to come from nsXPCException. It gets its location set in nsXPCException::Initialize() via an nsIStackFrame.

nsBaseDOMException appears to be a wrapper for another nsIException instance (possibly nsXPCException).

I cannot find any implementation of nsException, other than a header file with a class definition.

Trac:
Keywords: tbb-linkabilility deleted, tbb-fingerprinting, MikePerry201205 added

nsIStackFrame is implemented by XPCJSStackFrame, which appears to get the filename from either callers of XPCJSStackFrame::CreateStackFrameLocation() or from JS_GetScriptFilename().

And.. JSScript gets the filename from the ByteCodeEmitter's Parser object...

Aha! Neutron on IRC confirms that these paths are santized in Mozilla's official Firefox builds.

So this is due to something different between how we build Firefox for Mac and Linux vs our Windows builds.

Trac:
Owner: mikeperry to erinn
Component: Firefox Patch Issues to Tor bundles/installation

Btw: My money is on the FirefoxPortable cruft causing this issue. Other than that, I have no further insight into this bug, as I have no idea how our Windows build process works.

Trac:
Keywords: MikePerry201205 deleted, N/A added

Replying to mikeperry:

Btw: My money is on the FirefoxPortable cruft causing this issue. I just tried the official PortableApps Firefox and it sanitizes the paths too. Also, this issue is not introduced after manually installing Torbutton in the Portable Firefox.

Trac:
Cc: erinn, Sebastian, g.koppen@jondos.de to erinn, Sebastian, g.koppen@jondos.de, Shondoit

Issue is still triggered after uninstalling torbutton, https everywhere and noscript

Replying to mikeperry:

as I have no idea how our Windows build process works.

what do I have to do so that you will never need to say that again?

A firefox without the patches has the same issue, even when ran from the build directory - no portablefirefox contamination possible at that point.

This happens because firefox is not installed. When building a firefox installer and using that one, the path is properly obfuscated. Since it also doesn't happen for Portable Firefox, we should figure out what's different and how they manage to avoid leaking the path here.

Aha. we can "make package" which might help here. Now to figure out how to actually integrate it into the build process

Trac:
Status: new to assigned
Owner: erinn to Sebastian

Replying to Sebastian:

Aha. we can "make package" which might help here.

Intriguing. I wonder what else 'make package' changes.

Replying to Sebastian:

Replying to mikeperry:

as I have no idea how our Windows build process works.

what do I have to do so that you will never need to say that again?

Heh. Is my plan of annoying you to death by being a broken record working a little to well? ;)

I basically want a short, sweet document for bootstrapping a VM and building TBB, like you did for https://gitweb.torproject.org/torbrowser.git/tree/master:/docs/buildmachine_setups/osx.txt for Windows and Linux, too.

I know you're working on it. It's just that every time I run into a build-related issue, I am frustrated by the fact that I (and more importantly, others) have no idea how to help.

branch bug5299 in my repo has a fix. The second patch is pretty ugly, but it seems to work. We should fix this better once we have gotten rid of the dynamic part of the firefox build dir (the hostname/arch stuff behind the obj-)

Trac:
Status: assigned to needs_review

Branch 'bug5922' in my repo has a greatly sanitized version. I propose that one for review.

It looks like this just got merged? Is there a reason we chose Sebastian's version?

Replying to mikeperry:

It looks like this just got merged? Is there a reason we chose Sebastian's version? Sebastian's version doesn't work for clean build since it's missing the 'build' target. Besides that, it copies along a jsshell_win32.zip file since it resides in the same directory as the finished package.

My branch copies directly from the staging folder instead of packing the staging folder and unpacking the resulting zip file. More comments can be found in ./src/current-patches/mozilla-build/start-msvc.patch

I added the 're-bug5922' branch to my repo which is a rebased version of 'bug5922'

A fixed version is now out. It uses my version of the patch however, so I'm keeping this bug open for now so we can go with Shondoit's version later

Shondoit -- I merged your patch and am rebuilding the Windows Firefox with it. Thanks, and sorry I missed it before, but I didn't deliberately ignore it.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #5926 (moved)

mentioned in issue #9308 (closed)

mentioned in issue tpo/applications/tor-browser#5926 (closed)