Re: [tor-bugs] #13359 [Tor Browser]: Linux: update fails because bundled libstdc++.so.6 is not found

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13359: Linux: update fails because bundled libstdc++.so.6 is not found
-----------------------------+----------------------
     Reporter:  mcs          |      Owner:  gk
         Type:  defect       |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:  ff31-esr
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------

Comment (by gk):

 Replying to [comment:3 mikeperry]:
 > The problem with our -rpath setting was that it was to a fixed path that
 wasn't actually in use (/home/ubuntu/install/lib, IIRC). The argument by
 the commenter was that an "ubuntu" username on the machine might be able
 to create this path with a library in it, to compromise other users. I
 don't think the same argument applies to a relative rpath.
 >
 > If we can set a "$ORIGIN" -rpath relative to the current directory, we
 may have people complaining about things like #12736, but ultimately I
 don't think it is any worse than always LD_LIBRARY_PATH to the same
 directory.
 >
 > If I had to guess, there's probably code somewhere in the installation
 of updates in Firefox that is calling execle or execvpe with a blank
 environment. We could add LD_LIBRARY_PATH back in to this environment.
 >
 > I think a relative rpath is probably a cleaner solution though?

 I tend to agree. My main concern currently is that we are running short of
 time implementing and testing this properly for the upcoming release: 1)
 Getting it to work at all seems not so easy as passing "$ORIGIN" to the
 proper flags AND having it in the RPATH after linking turns out to be non-
 trivial. Seems I need to find the proper spell here... (we could do the
 workaround mentioned in https://enchildfone.wordpress.com/2010/03/23/a
 -description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/
 but I'd rather avoid that). 2) But even then we have our testsuite
 complaining about the now acceptable RPATH. 3) There are not all Firefox
 libs in /Browser but some are in /Browser/components. Thus, we might need
 some patches to the build logic to make sure everything has the proper
 RPATH. 4) There is pluggable transports build logic (fte comes to mind)
 that needs to get adapted and the result tested. So, I'd favor a stopgap
 not involving this change one or two days before we start our release
 building.

 I'd test the one mentioned in comment:4 but I currently lack the update
 testing setup. mcs: can you think of trying this idea (does not matter if
 you still have your tor related system libs installed in this case)? Would
 a patch from my side be of help (it would basically copy the libstdc++
 into the tor lib directory instead of the browser directory)?

 Other cheap workaround proposals are welcome.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13359#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs