Opened 6 years ago

Last modified 5 months ago

#13373 needs_revision enhancement

Get rid of LD_LIBRARY_PATH and use a relative RPATH/RUNPATH in Linux bundles

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, gitlab-tb-tor-browser-build
Cc: boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Relying on LD_LIBRARY_PATH in our start script can cause all sorts of pain (see #13359 for an example). We should take the cleaner approach to compile the binaries that need it with a relative RPATH/RUNPATH and get rid of LD_LIBRARY_PATH. We need to adapt our tests as well to make the pass if a RPATH/RUNPATH with ${ORIGIN} is showing up.

Child Tickets

Change History (10)

comment:1 Changed 5 years ago by gk

Severity: Normal

See: #18305 for another pain point with LD_LIBRARY_PATH. I guess fixing this ticket would have prevented the trouble outlined there in the first place.

comment:2 Changed 3 years ago by gk

Keywords: tbb-rbm added; tbb-gitian removed

Moving over to rbm

comment:3 Changed 2 years ago by gk

Have a look at #13359 where initial work got started to fix this ticket.

comment:4 Changed 2 years ago by sukhbir

Status: newneeds_review

For review (will need!):

This still has an issue but I thought I should submit the current state for review. The issue is that for selfrando and as per #22242, we do this in firefox/build:

219       [% IF c("var/selfrando") -%]
220         # remove RUNPATH added by selfrando (see #22242)
221         chrpath -d $LIB
222       [% END -%]

So this removes the RUNPATH for firefox.real even if we set it during the build (as in the above branch). So as per the current branch and if we remove the selfrando line, the RUNPATH looks like:

 0x000000000000001d (RUNPATH)            Library runpath: [/var/tmp/dist/selfrando/out/x86_64/bin:$ORIGIN/TorBrowser/Tor]

which is we want except we don't want it for selfrando? So how should we handle this? Should we set the RUNPATH for Firefox, then remove the one for selfrando selectively? Or should we not bother to compile Firefox with the RUNPATH and then later change it manually using chrpath? I am not sure what is the preferred approach.

Other things that remain: updating the tests in tor-browser-bundle-testsuite.git.

PS: I also fixed #24465 in this commit since it was (somewhat) related and is a one-line change.

comment:5 Changed 2 years ago by gk

Keywords: TorBrowserTeam201808R added

comment:6 Changed 2 years ago by gk

Keywords: TorBrowserTeam201809R added; TorBrowserTeam201808R removed

Moving review tickets to September

comment:7 Changed 2 years ago by gk

Keywords: TorBrowserTeam201810R added; TorBrowserTeam201809R removed

Moving review tickets to October

comment:8 Changed 2 years ago by gk

Keywords: TorBrowserTeam201810R removed
Status: needs_reviewneeds_revision

Looking at the patch we are still using LD_LIBRARY_PATH? But the plan was to get rid of it. What is preventing us from doing so (this needs at least some commenting)?

Are we good when updating from a Tor Browser version using the LD_LIBRARY_PATH approach to the new one implemented in this bug?

Please use a separate commit for the snowflake issue with the respective bug number.

Re the selfrando parts. I think using chrpath to get rid of the selfrando related bits seems like a good idea, as we are currently doing. Thus, just the $ORIGIN/TorBrowser/Tor should remain.

comment:9 Changed 14 months ago by gk

FWIW: the updater is built with RUNPATH $ORIGIN starting with esr68. So using the normal tool shows a false positive now, see #29818.

comment:10 Changed 5 months ago by gk

Keywords: gitlab-tb-tor-browser-build added

Add magic gitlab keyword.

Note: See TracTickets for help on using tickets.