Firefox 4 Tor Browser Bundle does not start on CentOS 5.6 (64Bit)
I tested the recent TBB [1] on CentOS 5.6:
./start-tor-browser ./start-tor-browser: line 53: pidof: command not found ./start-tor-browser: line 53: pidof: command not found
Launching Tor Browser Bundle for Linux in /home/ca/tor-browser_en-US
(:3800): GLib-GObject-WARNING **: IA__g_object_set_valist: object class GtkMenuItem' has no property named label'
(:3800): GLib-GObject-WARNING **: IA__g_object_set_valist: object class GtkCheckMenuItem' has no property named label'
Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
Exited cleanly. Goodbye.
Activity
changed milestone to %TorBrowserBundle 2.2.x-stable
(Just to quote the output so it's readable in Trac:)
Replying to tagnaq:
I tested the recent TBB [1] on CentOS 5.6:
./start-tor-browser ./start-tor-browser: line 53: pidof: command not found ./start-tor-browser: line 53: pidof: command not found Launching Tor Browser Bundle for Linux in /home/ca/tor-browser_en-US (<unknown>:3800): GLib-GObject-WARNING **: IA__g_object_set_valist: object class `GtkMenuItem' has no property named `label' (<unknown>:3800): GLib-GObject-WARNING **: IA__g_object_set_valist: object class `GtkCheckMenuItem' has no property named `label' Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed Exited cleanly. Goodbye.Trac:
Cc: N/A to tagnaq@gmail.comThis is probably a result of dynamically linking Firefox/libxul to whatever libgtk-2.0.so.0 is installed on the host system. libxul.so is already 14.7 MiB in the Firefox 6 TBB for Linux; we do not have room to add Gtk to the current bundles.
Here are the options I see:
- Implement and deploy Thandy, and have it install our own Gtk. This will waste more disk space (and initial download bandwidth) on systems running non-antique distributions, unless we automagically detect whether a suitable Gtk is installed already and only grab another one if that's not good enough. That, in turn, leaks some information about where a TBB has been used/installed on a TBB kept on a USB stick.
- Replace Vidalia with something that uses Gtk, and include Gtk in the bundle. This would probably cost way too much developer time, would still waste space in the bundle on non-antique distros, and would probably make the bundle even bigger than it is now with Qt shipped in it.
Any other ideas?
Maybe we can just ship the "correct" libstdc++ along with our other libs?: http://wiki.centos.org/TipsAndTricks/Firefox4onCentOS5
Seems a bit icky to me, but it might work. I will test it in a VM.
I'm not convinced we should ship all libs ever that Firefox depends on. Being able to run Firefox at all is a prerequisite of TBB, but that's less of an obvious hard line when there are multiple versions of Firefox floating around. Having Thandy get to a point where it is able to detect and download the correct libs on an as-needed basis sounds nice, but making all of the libs in such a way that we feel comfortable guaranteeing them is a different story.
Replying to erinn:
Maybe we can just ship the "correct" libstdc++ along with our other libs?: http://wiki.centos.org/TipsAndTricks/Firefox4onCentOS5
Seems a bit icky to me, but it might work. I will test it in a VM.
The error message tagnaq posted appears to be a Gtk version incompatibility, not an incompatibility with the system's version of
libstdc++. I would be very surprised if shippinglibstdc++in the bundle helped.I'm not convinced we should ship all libs ever that Firefox depends on. Being able to run Firefox at all is a prerequisite of TBB, but that's less of an obvious hard line when there are multiple versions of Firefox floating around. Having Thandy get to a point where it is able to detect and download the correct libs on an as-needed basis sounds nice, but making all of the libs in such a way that we feel comfortable guaranteeing them is a different story.
One option is to explicitly drop support for CentOS/RHEL. On the other hand, using system shared libraries when they are available is a security hole for some people (e.g. it's easier for Red Flag Linux to mess with TBB if TBB loads attacker-supplied Gtk libraries than if the attacker has to know how to dig around in TBB's memory to find out what the user is doing), so it would be helpful to have Thandy be able to grab all of the libraries TBB needs.
It is a hard, ugly problem, though.
