Opened 13 months ago

Last modified 13 months ago

#25305 needs_information defect

Tor Browser refuses to start / XDG_CONFIG_DIRS environment variable segfaults Tor Browser

Reported by: adrelanos Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-crash
Cc: whonix-devel@…, adrelanos@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

More than 6 entries (each entry is devices by a colon) will segfault Tor Browser. Here is a simplified minimal example that shows how to trigger this bug.

Happening with both, Tor Browser 7.5 and 8.0a1 on Debian stretch.

segfaults:

XDG_CONFIG_DIRS=x:x:x:x:x:x:x ./start-tor-browser.desktop --debug

./Browser/start-tor-browser: line 370: 3249 Segmentation fault TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser" -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null

working:

XDG_CONFIG_DIRS=x:x:x:x:x:x ./start-tor-browser.desktop --debug

This is to show that the existence or content of the folder is unrelated here.

Relevance:

Of course nobody uses XDG_CONFIG_DIRS=x:x:x:x:x:x as their XDG_CONFIG_DIRS.

Real world example that is failing is in Whonix, where settings are pre-configured. Whonix is using:

XDG_CONFIG_DIRS=/usr/share/torbrowser-default-browser/:/usr/share/security-misc/:/usr/share/kde-apper-no-autoupdate/:/usr/share/anon-ws-kde-startmenu/:/usr/share/anon-apps-config/:/usr/share/open-link-confirmation/:/etc/xdg

That segfaults Tor Browser.

firefox-esr (from Debian stretch) does not have this issue.

#21804 was a similar issue where a long XDG_CONFIG_DIRS environment variable resulted in Tor Browser refusing to start.

Child Tickets

Change History (3)

comment:1 Changed 13 months ago by adrelanos

Cc: adrelanos@… added
Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team

comment:2 Changed 13 months ago by gk

Keywords: tbb-crash added

comment:3 Changed 13 months ago by gk

Status: newneeds_information

Could you easily test whether Debian testing has the same problem? I can't reproduce your issue on such a system while I still see it on Debian oldstable. One difference between the Debian builds and ours is that we still build with GTK2 and it seems that some GTK2 related libraries are high up on the stack trace I get on an oldstable system.

Note: See TracTickets for help on using tickets.