Tor Browser v12.0.4 not working, older system

For legacy reasons, I’m running Ubuntu 14.04 and cannot upgrade to a newer distro.

Last night I attempted to launch Tor Browser, it wanted to update and then: nothing. What is this XPCOM thing and why isn’t there a fallback, for legacy and other users who for one reason or another, cannot update to newer (or the newest) Linux distro?

Isn’t this project supposed to support users in third world and sketchy locations, where suboptimal hardware and software cannot be avoided, instead of shafting them by breaking backwards compatibility?

$ ./start-tor-browser.desktop --verbose
Launching ‘./Browser/start-tor-browser --detach --verbose’…
XPCOMGlueLoad error for file /home/intern/Downloads/browsers/tor/tor-browser/Browser/
/home/intern/Downloads/browsers/tor/tor-browser/Browser/ undefined symbol: gdk_window_show_window_menu
Couldn’t load XPCOM.

1 Like

Here’s a workaround. Create stub.c file next to firefox binary and put the following code:

include <stdio.h>
void gdk_window_show_window_menu(void) {}

Compile it like this:
cc -shared -o stub.c -fPIC

Run it:
LD_PRELOAD=./ ./start-tor-browser

1 Like

So this solution may work for this particular problem, and odds are it will be fine since that function is used to activate the title bar menu. I would guess this is part of the show/hide titlebar system and Firefox isn’t ‘really’ showing the window manager’s title bar but is instead emulating it (but that’s neither here nor there).

For those following along at home, the solution posted by @diver creates a shared library which provides a definition of the missing required function, and then instructs Tor Browser to also load the library containing said function so it resolves the undefined symbol error (symbol being a function name).

However, in GENERAL you shouldn’t do this type of thing without both understanding the code being injected, and the role of the functionality it is replacing/implementing.

IE you definitely do not want to run a stub library with a function such as:

// this is fine ;)
bool openssl_signature_is_valid(uint8_t* sig, size_t sig_size, uint8_t msg, size_t msg_size) { 
    return true; 

But this general trick can be helpful in some circumstances where the missing function is trivial or unimportant.

@rjh427 The real answer here of course is upgrade your OS, 14.04 is like 5 years old. Go hop on debian stable or something, it will probably support your hardware if legacy Ubuntu does. This situation is only going to get worse for you as we upgrade to Firefox ESR 128 this summer.

As for why we don’t provide fallbacks for legacy, there’s a few reasons:

  • Capacity: supporting legacy platforms is hard work, we don’t have enough people or expertise to support old versions of Windows, macOS, Linux, and Android
  • It’s a bad idea: unsupported platforms have unpatched vulnerabilities; shipping a web browser that ran on these platforms would be akin to giving you a car with faulty brakes; sure it will run but it won’t end well for you. On top of that, older platforms lack functionality required by the software; older versions of windows lack APIs required by c-tor to perform certain cryptography operations safely as well as operating system primtives required for the security sandbox.
  • Your system is broken anyway: Even if we could solve the above problems and were capable of shipping a secure browser for your particularly unsupported platform, everything else running on your system is not.

Please update.


The current survivors of the “I modded Tor Browser Club”

And in recent news, here is a relevant example of how supporting legacy platforms can really bite you in the tuchus:

high-level tldr; PuTTY back in the day was built on Windows before it had support for a cryptographically secure source of random numbers. So to generate some ‘random’ numbers for parts of their cryptography, they instead use a clever hashing scheme to get some random bytes. And, they would have gotten away with it too except that due to some seemingly unrelated realities elsewhere and whoops now adversaries can derive private keys when a particular algorithm is used.

The solution of course is to use the ‘new’ relevant Windows crypto APIs :grin:

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.