Opened 8 years ago

Closed 7 years ago

#2900 closed defect (fixed)

Firefox 4 Tor Browser Bundle does not start on CentOS 5.6 (64Bit)

Reported by: tagnaq Owned by: erinn
Priority: Medium Milestone: TorBrowserBundle 2.2.x-stable
Component: Applications/Tor bundles/installation Version:
Severity: Keywords:
Cc: tagnaq@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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 : IAg_object_set_valist: object class GtkMenuItem' has no property named label'

(<unknown>:3800): GLib-GObject-WARNING : IAg_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.

[1] https://www.torproject.org/dist/torbrowser/linux/tor-browser-gnu-linux-x86_64-2.2.23-1-alpha-en-US.tar.gz

Child Tickets

Change History (9)

comment:1 in reply to:  description Changed 8 years ago by rransom

(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.

[1] https://www.torproject.org/dist/torbrowser/linux/tor-browser-gnu-linux-x86_64-2.2.23-1-alpha-en-US.tar.gz

comment:2 Changed 8 years ago by tagnaq

Cc: tagnaq@… added

comment:3 Changed 8 years ago by rransom

This 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?

comment:4 Changed 8 years ago by 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.

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.

comment:5 in reply to:  4 Changed 8 years ago by rransom

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 shipping libstdc++ 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.

comment:6 Changed 8 years ago by mikeperry

Can we create a separate library tarball that the startup script can find?

comment:7 Changed 8 years ago by mikeperry

Milestone: TorBrowserBundle 2.2.x-stable

comment:8 Changed 8 years ago by Sebastian

Status: newneeds_information

Is this fixed now that we build against and older gtk? (Try one of the non-most recent TBBs, which Erinn built, because I built against a new gtk)

comment:9 Changed 7 years ago by cypherpunks

Resolution: fixed
Status: needs_informationclosed

Successfully tested with TBB x86_64_2.2.37-1-dev-en-US
on CentOS 6.2 64bit.

Note: See TracTickets for help on using tickets.