Opened 8 months ago

Closed 3 months ago

#25485 closed defect (fixed)

Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)

Reported by: cypherpunks Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr, TorBrowserTeam201808R
Cc: mcs, brade Actual Points:
Parent ID: #20866 Points:
Reviewer: Sponsor:

Description

I noticed that clicking on the Open Directory button in the Profile Directory entry in about:support fails with the following error:

nautilus: /home/systemdsucks/Desktop/tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
nautilus: /home/systemdsucks/Desktop/tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /usr/lib/x86_64-linux-gnu/libmircommon.so.7)

Child Tickets

Change History (57)

comment:1 Changed 8 months ago by gk

Status: assignedneeds_information

I wonder where the libmir* requirement is coming from. Cypherpunk: What Linux system is that and how are you extracting/starting Tor Browser?

Last edited 3 months ago by gk (previous) (diff)

comment:2 in reply to:  1 Changed 8 months ago by yawning

Replying to gk:

I wonder where the libmir* requirement is coming from.

Stuff on the user's system (in this case nautlius) is compiled against it. My bet here would be Gtk 3 and or Mesa, but it doesn't really matter.

If Tor Browser forks/execs things that are not part of the browser bundle (such as, oh, the file manager), it should clear LD_LIBRARY_PATH.

comment:3 in reply to:  1 Changed 8 months ago by cypherpunks

Status: needs_informationnew

Replying to gk:

I wonder where the libmir* requirement is coming from. Cyperpunk: What Linux system is that and how are you extracting/starting Tor Browser?

Ubuntu 17.10. For that case I did cd Browser && ./start-tor-browser --debug.

comment:4 Changed 5 months ago by igt0

I am having the same problem with one of my Ubuntu machines.

LD_LIBRARY_PATH=<PathToTor>/tor-browser_en-US/Browser/TorBrowser/Tor/ ./firefox --class 'Tor Browser' -profile TorBrowser/Data/Browser/profile.default

XPCOMGlueLoad error for file <PATH>/tor-browser_en-US/Browser/libmozgtk.so:
<PATH>/tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
Couldn't load XPCOM.

The libmozgtk has as dependency libmirclient.

ldd <PATH>/tor-browser_en-US/Browser/libmozgtk.so
	linux-vdso.so.1 =>  (0x00007fff46484000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f109d710000)
	libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007f109cdfc000)
	libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007f109caf1000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f109c711000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f109c50d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f109d92f000)
	libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f109c309000)
	libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f109c0fc000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f109bdc3000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f109bbb3000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f109b9ad000)
	libcairo-gobject.so.2 => /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007f109b7a4000)
	libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f109b493000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f109b26f000)
	libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f109b049000)
	libatk-bridge-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007f109ae1a000)
	libepoxy.so.0 => /usr/lib/x86_64-linux-gnu/libepoxy.so.0 (0x00007f109ab24000)
	libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f109a90e000)
	libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f109a6c0000)
	libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f109a47d000)
	libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f109a0e2000)
	libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f1099e8e000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f1099b7a000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1099824000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f1099621000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f1099416000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f109920c000)
	libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f1099009000)
	libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f1098e06000)
	libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f1098bc7000)
	libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f10989bf000)
	libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f10987bd000)
	libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f10985ae000)
	libmirclient.so.9 => /usr/lib/x86_64-linux-gnu/libmirclient.so.9 (0x00007f1098306000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f10980f4000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1097eec000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1097c39000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1097a12000)
	libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f109776c000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f109753a000)
	libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f1097337000)
	libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f109712a000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1096f20000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1096d03000)
	libatspi.so.0 => /usr/lib/x86_64-linux-gnu/libatspi.so.0 (0x00007f1096ad3000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f1096887000)
	libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f10965f3000)
	libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f10963ea000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f10961bf000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f1095f97000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f1095d7d000)
	libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007f1095b2b000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f1095923000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f10956b1000)
	libmircommon.so.7 => /usr/lib/x86_64-linux-gnu/libmircommon.so.7 (0x00007f1095475000)
	libmirprotobuf.so.3 => /usr/lib/x86_64-linux-gnu/libmirprotobuf.so.3 (0x00007f10951f1000)
	libcapnp-0.5.3.so => /usr/lib/x86_64-linux-gnu/libcapnp-0.5.3.so (0x00007f1094f6c000)
	libmircore.so.1 => /usr/lib/x86_64-linux-gnu/libmircore.so.1 (0x00007f1094d5f000)
	libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x00007f1094b5b000)
	libprotobuf-lite.so.10 => /usr/lib/x86_64-linux-gnu/libprotobuf-lite.so.10 (0x00007f109490b000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1094585000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f109436e000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f109416a000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1093f64000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f1093cdf000)
	libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f1093ab2000)
	libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f10938ab000)
	libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f1093661000)
	libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x00007f1093448000)
	libkj-0.5.3.so => /usr/lib/x86_64-linux-gnu/libkj-0.5.3.so (0x00007f1093221000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f109300c000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f1092cfe000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1092ad8000)
	liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f10928c0000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f10926bb000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f10924a6000)



comment:5 Changed 5 months ago by gk

Keywords: ff60-esr added
Priority: MediumHigh

comment:6 Changed 5 months ago by gk

Keywords: TorBrowserTeam201806 added
Priority: HighVery High

#26589 is a duplicate.

comment:7 Changed 5 months ago by gk

Resolution: worksforme
Status: newclosed

privacy.donottrackheader.enabled is set to false in my Tor Browser. Thus, it seems you messed with your settings and have it enabled now.

comment:8 Changed 5 months ago by gk

Resolution: worksforme
Status: closedreopened

Ugh, wrong ticket.

comment:9 Changed 4 months ago by boklm

It seems that the issue is that libgdk-3.so.0 on Ubuntu is linked to libmirclient.so.9, which is linked to a newer version of libstdc++.so.6 than the one we ship.

Some (probably not good) solutions could be:

  • building and shipping a libgdk-3.so.0 (and maybe libgtk3?) that is not linked to libmirclient.so.9. However this will increase the complexity, build time, and size of our bundles.
  • building and shipping a libmirclient.so.9 that is linked to our version of libstdc++.so.6.

I think a better option might be to avoid having our version of libstdc++.so.6 in LD_LIBRARY_PATH when the version installed on the system is newer. Maybe the start-tor-browser script could detect which version of libstdc++.so.6 is available and only add our version to LD_LIBRARY_PATH when needed.

comment:10 Changed 4 months ago by gk

Do we actually still need to ship that lib?

comment:11 in reply to:  10 Changed 4 months ago by boklm

Replying to gk:

Do we actually still need to ship that lib?

I think we need to ship libstdc++.so.6 for the systems where the installed version is too old. As we are building using gcc 6.4.0, it seems our binaries will require CXXABI_1.3.10 added with gcc 6.1.0:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Some of the distributions built using a gcc older than 6.1.0 are:

  • Ubuntu 16.04LTS (gcc 5.3.1)
  • Centos 7 (gcc 4.8.5)

comment:12 Changed 4 months ago by gk

Keywords: TorBrowserTeam201807 added; TorBrowserTeam201806 removed

Moving first batch of tickets to July 2018

comment:13 Changed 4 months ago by yawning

For what it's worth, this also is the root cause of #20866.

comment:14 Changed 4 months ago by Hello71

what's wrong with rpath?

comment:15 Changed 4 months ago by sukhbir

Status: reopenedneeds_revision

For review:

https://github.com/azadi/tor-browser-build-1/tree/bug-25485

This is tested on Ubuntu 17.04 (gcc 7; newer) as well as Ubuntu 16.04 (gcc 5.3.1; older). To initiate the ABI check, we compare the installed gcc version with the bundled Tor Browser version 6.4.0. If the installed version is more recent, we remove the bundled libstdc++.so.6 from Browser/TorBrowser/Tor, which removes it from LD_LIBRARY_PATH.

I am guessing this should suffice, or should we follow the symlink for libstdc++.so.6 and then compare the CXXABI, like for Ubuntu 17.04:

$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24  | grep CXXABI_[[:digit:]] | sort -Vr | head -1
CXXABI_1.3.11

and then compare it with the Tor Browser version:

$ strings Browser/TorBrowser/Tor/libstdc++.so.6  | grep CXXABI_[[:digit:]] | sort -Vr | head -1
CXXABI_1.3.10

which tells us the same thing and instead of comparing the version strings, we can compare this but I thought the gcc version is more direct.

(As indicated in comment:14, we should consider using rpath as discussed in #13373 but I am not focusing on that for now.)

comment:16 Changed 4 months ago by sukhbir

Status: needs_revisionneeds_review

comment:17 Changed 4 months ago by Hello71

I don't think this is correct. the gcc version has no particular relation to the glibc version. moreover, it may not even be installed. removing libraries is not a good idea, as the user may want to move their installation to another machine (or share it between two OSes on the same machine). additionally, grepping the versions is not a reliable way of checking ABI compatibility, as there may be missing symbols as well. the right-er way to do this is to build an old binary and a new binary, try to run the new binary on the system, and if it fails, use our library. this doesn't quite account for missing symbols though.

comment:18 Changed 4 months ago by gk

Status: needs_reviewneeds_revision

Replying to sukhbir:

For review:

https://github.com/azadi/tor-browser-build-1/tree/bug-25485

This is tested on Ubuntu 17.04 (gcc 7; newer) as well as Ubuntu 16.04 (gcc 5.3.1; older). To initiate the ABI check, we compare the installed gcc version with the bundled Tor Browser version 6.4.0. If the installed version is more recent, we remove the bundled libstdc++.so.6 from Browser/TorBrowser/Tor, which removes it from LD_LIBRARY_PATH.

That makes me nervous. It is not unusual (at least for me) to have different compiler versions around on my Linux box and use them. If I happen to use a newer version than usual your patch my blow away my libstdc++ which Tor Browser ships but switching back to my regular compiler suddenly breaks Tor Browser now.

I think trying to figure out the installed libstdc++ version and comparing it to the one we ship and not using the latter if the former is newer seems like a more plausible idea to me. However, there might be pitfalls we'd like to avoid in this scenario as well.

comment:19 Changed 4 months ago by sukhbir

So the question then is that if it's not strings, then what would be a good way of finding out the installed version of libstdc++ to compare with the bundled version? Would parsing the readelf output be a better fit?

comment:20 Changed 4 months ago by Hello71

not really. it still doesn't fix the symbols issue, and worse, binutils is also not necessarily installed.

comment:21 Changed 4 months ago by Hello71

how does standard firefox fix this?

comment:22 in reply to:  21 Changed 4 months ago by sukhbir

Replying to Hello71:

how does standard firefox fix this?

They don't have this issue; see comment:9.

comment:23 in reply to:  19 ; Changed 4 months ago by boklm

Replying to sukhbir:

So the question then is that if it's not strings, then what would be a good way of finding out the installed version of libstdc++ to compare with the bundled version? Would parsing the readelf output be a better fit?

Maybe we could build a small c++ program linked with our libstdc++ and using the latest CXXABI. If running this program from start-tor-browser fails then we know that we need to add our libstdc++ to LD_LIBRARY_PATH.

comment:24 in reply to:  14 ; Changed 4 months ago by boklm

Replying to Hello71:

what's wrong with rpath?

How would it help with this issue? I think using rpath instead of LD_LIBRARY_PATH to use our libstdc++ library does not remove the issue that our libstdc++ can be too old for libgdk-3.so.0 or other installed libraries on some systems.

comment:25 in reply to:  24 Changed 4 months ago by Hello71

Replying to boklm:

Replying to sukhbir:

So the question then is that if it's not strings, then what would be a good way of finding out the installed version of libstdc++ to compare with the bundled version? Would parsing the readelf output be a better fit?

Maybe we could build a small c++ program linked with our libstdc++ and using the latest CXXABI. If running this program from start-tor-browser fails then we know that we need to add our libstdc++ to LD_LIBRARY_PATH.

isn't that what I said to do?

Replying to boklm:

Replying to Hello71:

what's wrong with rpath?

How would it help with this issue? I think using rpath instead of LD_LIBRARY_PATH to use our libstdc++ library does not remove the issue that our libstdc++ can be too old for libgdk-3.so.0 or other installed libraries on some systems.

DT_RUNPATH to be specific, not DT_RPATH. it only applies to the immediate dependencies, so it solves the immediate problem. it doesn't fix *data* format changing though, so for example passing a std::string between a new lib and an old lib might crash or do something bad.

comment:26 Changed 4 months ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201807 removed

Move our tickets to August.

comment:27 in reply to:  23 Changed 4 months ago by boklm

Replying to boklm:

Replying to sukhbir:

So the question then is that if it's not strings, then what would be a good way of finding out the installed version of libstdc++ to compare with the bundled version? Would parsing the readelf output be a better fit?

Maybe we could build a small c++ program linked with our libstdc++ and using the latest CXXABI. If running this program from start-tor-browser fails then we know that we need to add our libstdc++ to LD_LIBRARY_PATH.

To make a small program using GLIBCXX_3.4.22, we need to use some function that was added with this version. We can find that by looking in the file libstdc++-v3/config/abi/pre/gnu.ver from gcc sources:
https://github.com/gcc-mirror/gcc/blob/gcc-6_4_0-release/libstdc%2B%2B-v3/config/abi/pre/gnu.ver#L1869

It seems that std::uncaught_exception() is one of them. So we could use the example code from this page:
https://en.cppreference.com/w/cpp/error/uncaught_exception

#include <iostream>
#include <exception>
#include <stdexcept>
 
struct Foo {
    int count = std::uncaught_exceptions();
    ~Foo() {
        std::cout << (count == std::uncaught_exceptions()
            ? "~Foo() called normally\n"
            : "~Foo() called during stack unwinding\n");
    }
};
int main()
{
    Foo f;
    try {
        Foo f;
        std::cout << "Exception thrown\n";
        throw std::runtime_error("test exception");
    } catch (const std::exception& e) {
        std::cout << "Exception caught: " << e.what() << '\n';
    }
}

When I build this program using gcc 6.4.0, and I try to run it using my system's libstdc++.so.6, it fails with:

$ ./out/test/a.out
./out/test/a.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./out/test/a.out)
./out/test/a.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./out/test/a.out)

But it works if I add Tor Browser's libstdc++.so.6 to LD_LIBRARY_PATH.

So we could run this small program from start-tor-browser to check if the system provides a recent libstdc++.so.6, and only if it fails add our version to LD_LIBRARY_PATH.

comment:28 Changed 3 months ago by sukhbir

Status: needs_revisionneeds_review

For review:

https://github.com/azadi/tor-browser-build-1/tree/bug-25485-rev1

I decided to move the bundled libstdc++.so.6 to an additional Lib directory to make it easier to deal with LD_LIBRARY_PATH. Let me know if you prefer another way. Tested on Ubuntu 16.04.

comment:29 Changed 3 months ago by sukhbir

Additionally, I decided to put this projects/firefox and not projects/tor-browser as gcc/g++ was already in scope for /firefox and I didn't want to bring it in for /tor-browser.

Last edited 3 months ago by sukhbir (previous) (diff)

comment:30 in reply to:  28 ; Changed 3 months ago by boklm

Replying to sukhbir:

I decided to move the bundled libstdc++.so.6 to an additional Lib directory to make it easier to deal with LD_LIBRARY_PATH. Let me know if you prefer another way. Tested on Ubuntu 16.04.

Yes, moving it to a sub-directory sounds good. I'm thinking that maybe that sub-directory should be named something like libstdc++ to make it more clear what it is.

comment:31 in reply to:  30 Changed 3 months ago by sukhbir

Replying to boklm:

Replying to sukhbir:

I decided to move the bundled libstdc++.so.6 to an additional Lib directory to make it easier to deal with LD_LIBRARY_PATH. Let me know if you prefer another way. Tested on Ubuntu 16.04.

Yes, moving it to a sub-directory sounds good. I'm thinking that maybe that sub-directory should be named something like libstdc++ to make it more clear what it is.

OK I updated that to libstdc++. I will submit the new branch after the complete review in case there are other changes.

comment:32 Changed 3 months ago by boklm

Status: needs_reviewneeds_revision

I think we could add a comment in projects/firefox/abicheck.cc mentioning this ticket, and explaining that we found that this program is requiring GLIBCXX_3.4.22, which make it useful to check that the required version of libstdc++ is available.

Otherwise the changes look good to me.

comment:33 Changed 3 months ago by sukhbir

Status: needs_revisionneeds_review

Branch with the review changes (comments in abicheck.cc and updated directory name):

https://github.com/azadi/tor-browser-build-1/tree/bug-25485-rev2

comment:34 in reply to:  33 Changed 3 months ago by boklm

Resolution: fixed
Status: needs_reviewclosed

Replying to sukhbir:

Branch with the review changes (comments in abicheck.cc and updated directory name):

https://github.com/azadi/tor-browser-build-1/tree/bug-25485-rev2

Thanks! I pushed this to master as commit 6a89049c0d1200302a59f74e71151466ddae5582.

comment:35 Changed 3 months ago by gk

Are you sure this does not break Linux users during an update? Because the update process is not touching LD_LIBRARY_PATH (see: comment:10:ticket:13359) it seems to me after removing the libstdc++ from the old location and adding it to the new one there is the risk that Tor Browser won't start anymore as LD_LIBRARY_PATH is still pointing to the old one.

comment:36 Changed 3 months ago by gk

Cc: mcs brade added

comment:37 Changed 3 months ago by boklm

Resolution: fixed
Status: closedreopened

Ah this is a good point, the browser will probably fail to restart on the systems where our version of libstdc++ is required.

I am wondering if we could update LD_LIBRARY_PATH in the same way as the start script, during the update process, before restarting the browser.

comment:38 Changed 3 months ago by gk

Note that the patch broke our nightly builds for Linux as well (see: #27101).

Last edited 3 months ago by gk (previous) (diff)

comment:39 in reply to:  37 ; Changed 3 months ago by mcs

Replying to boklm:

Ah this is a good point, the browser will probably fail to restart on the systems where our version of libstdc++ is required.

Kathy and I agree that this change will cause the browser to fail to start after an update on systems that require our bundled libstdc++. A good catch by gk.

I am wondering if we could update LD_LIBRARY_PATH in the same way as the start script, during the update process, before restarting the browser.

The problem with this suggestion is that the updater that will be used is already on people's systems, so we cannot make changes to it :)

In general, I think we are putting too many important things inside start-tor-browser. Or to put it another way: after an update the browser should be started the same way as when users start the browser. In an ideal world, ./firefox would do everything necessary. We could move all of the start-tor-browser code into a script named firefox and rename the actual binary to something else)... but I don't know what that would break.

comment:40 in reply to:  39 Changed 3 months ago by boklm

Replying to mcs:

Replying to boklm:

Ah this is a good point, the browser will probably fail to restart on the systems where our version of libstdc++ is required.

Kathy and I agree that this change will cause the browser to fail to start after an update on systems that require our bundled libstdc++. A good catch by gk.

Alternatively we could keep our bundled libstdc++ in the default path, and add a new directory containing links to all libraries except libstdc++ to use it on systems with a recent libstdc++. This would fix the issue on systems where our bundled libstdc++ is required, but would cause issues on systems affected by #26589 so it is not clear if it is better.

I am wondering if we could update LD_LIBRARY_PATH in the same way as the start script, during the update process, before restarting the browser.

The problem with this suggestion is that the updater that will be used is already on people's systems, so we cannot make changes to it :)

In general, I think we are putting too many important things inside start-tor-browser. Or to put it another way: after an update the browser should be started the same way as when users start the browser. In an ideal world, ./firefox would do everything necessary. We could move all of the start-tor-browser code into a script named firefox and rename the actual binary to something else)... but I don't know what that would break.

Setting LD_LIBRARY_PATH in a script named firefox sounds like a good thing to try.

comment:41 in reply to:  39 ; Changed 3 months ago by sukhbir

Replying to mcs:

In general, I think we are putting too many important things inside start-tor-browser. Or to put it another way: after an update the browser should be started the same way as when users start the browser. In an ideal world, ./firefox would do everything necessary. We could move all of the start-tor-browser code into a script named firefox and rename the actual binary to something else)... but I don't know what that would break.

I am not sure but doesn't that break the updater as well? Or would it simply replace the Firefox executable with the script and add the new binary?

comment:42 in reply to:  41 Changed 3 months ago by mcs

Replying to sukhbir:

I am not sure but doesn't that break the updater as well? Or would it simply replace the Firefox executable with the script and add the new binary?

That should not break updates. Patching, adding, and removing files should be handled correctly.

comment:43 Changed 3 months ago by boklm

I pushed in branch bug_25485_v2 a patch that is renaming firefox to firefox.real, and adding a wrapper script as firefox that is setting LD_LIBRARY_PATH:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754

A browser built with this patch is starting correctly. I will now try to apply it as an update from 8.0a9 to see if that works too.

comment:44 Changed 3 months ago by boklm

Keywords: TorBrowserTeam201808R added; TorBrowserTeam201808 removed
Status: reopenedneeds_review

The patch in branch bug_25485_v3 is fixing the permissions on firefox:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754

I have not been able to test an update from 8.0a9 yet. It seems the pref app.update.url.override (which I think disabled signature verification) does not exist anymore. I tried manually installing the mar file, following the instruction from this page:
https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file
But it complains about missing signature:

ERROR: There must be at least one signature.

So I am not sure if there is an easy way to test an update, without signing it.

I uploaded my build at:
https://people.torproject.org/~boklm/tmp/bug_25485/
https://people.torproject.org/~boklm/tmp/bug_25485/sha256sums-unsigned-build.txt.asc

comment:45 in reply to:  44 Changed 3 months ago by mcs

Replying to boklm:

So I am not sure if there is an easy way to test an update, without signing it.

I don't know of s way to test without a signed MAR file. Kathy and I usually build from a slightly modified tor-browser tree in which we have replaced release_primary.der and release_secondary.der with our own files, which of course allows us to create and sign MAR files using our own key. But the entire process is inconvenient.

comment:46 Changed 3 months ago by mcs

And in case you did not find it yet, you can override the default update URL by opening the Browser Console (Alt+Shift+J / Cmd-Shift+J), and then executing a command similar to:

Services.prefs.getDefaultBranch(null).setCharPref("app.update.url", "https://myserver.com/tor/update_3/%CHANNEL%/%BUILD_TARGET%/%VERSION%/%LOCALE%");

comment:47 in reply to:  44 ; Changed 3 months ago by gk

Replying to boklm:

The patch in branch bug_25485_v3 is fixing the permissions on firefox:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754

I have not been able to test an update from 8.0a9 yet. It seems the pref app.update.url.override (which I think disabled signature verification) does not exist anymore. I tried manually installing the mar file, following the instruction from this page:
https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file

21:05 <+GeKo> i am wondering whether that would actually test what we want to test
21:06 <+GeKo> we already know that starting tor browser with your patch applied works but that is basically what you are doing with this method

That said I can help with the signing part and we can hold off starting the build until tomorrow for that.

comment:48 in reply to:  47 ; Changed 3 months ago by boklm

Replying to gk:

Replying to boklm:

The patch in branch bug_25485_v3 is fixing the permissions on firefox:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754

I have not been able to test an update from 8.0a9 yet. It seems the pref app.update.url.override (which I think disabled signature verification) does not exist anymore. I tried manually installing the mar file, following the instruction from this page:
https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file

21:05 <+GeKo> i am wondering whether that would actually test what we want to test
21:06 <+GeKo> we already know that starting tor browser with your patch applied works but that is basically what you are doing with this method

Yes, manually installing the mar file might not be enough. With a signed mar, I can generate some update xml, and test the update by changing app.update.url.

That said I can help with the signing part and we can hold off starting the build until tomorrow for that.

I am not sure if the updater will accept an update which is not in the same channel, and with tbb-nightly as the version number. So I did a new build with the same patch, but building an alpha, with version number 8.0a9.1:
https://people.torproject.org/~boklm/tmp/bug_25485-v2/

comment:49 in reply to:  48 Changed 3 months ago by gk

Replying to boklm:

[snip]

I am not sure if the updater will accept an update which is not in the same channel, and with tbb-nightly as the version number. So I did a new build with the same patch, but building an alpha, with version number 8.0a9.1:
https://people.torproject.org/~boklm/tmp/bug_25485-v2/

I've uploaded the signed MAR file:

https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-8.0a9.1_signed_en-US.mar
https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-8.0a9.1_signed_en-US.mar.asc

Applying the MAR file manually to a fresh 8.0a9 (following the steps in https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file) works for me at least.

comment:50 Changed 3 months ago by boklm

I made this update.xml file:
https://people.torproject.org/~boklm/tmp/bug_25485-v2/update.xml

And after running this in the browser console:

Services.prefs.getDefaultBranch(null).setCharPref("app.update.url", "https://people.torproject.org/~boklm/tmp/bug_25485-v2/update.xml");

the update from 8.0a9 worked fine for me.

comment:51 Changed 3 months ago by gk

Parent ID: #20866

comment:52 in reply to:  4 Changed 3 months ago by boklm

Replying to igt0:

I am having the same problem with one of my Ubuntu machines.

LD_LIBRARY_PATH=<PathToTor>/tor-browser_en-US/Browser/TorBrowser/Tor/ ./firefox --class 'Tor Browser' -profile TorBrowser/Data/Browser/profile.default

XPCOMGlueLoad error for file <PATH>/tor-browser_en-US/Browser/libmozgtk.so:
<PATH>/tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
Couldn't load XPCOM.

The libmozgtk has as dependency libmirclient.

Which Ubuntu version was it?

On my Ubuntu 18.04 install, libmozgtk does not have a dependency on libmirclient anymore.

comment:53 Changed 3 months ago by boklm

I was able to reproduce the issue on an Ubuntu 17.10. But because version 8.0a9 doesn't start, we can't test the update from 8.0a9 to 8.0a9.1.

I tried updating version 7.5.6 to 8.0a9.1, but nothing happens when I click on the "Restart Tor Browser to Update" button, and I see this in the logs:

*** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist
*** AUS:SVC Creating UpdateService
*** AUS:SVC Checker: checkForUpdates, force: true
*** AUS:SVC Checker:getUpdateURL - update URL: https://people.torproject.org/~boklm/tmp/bug_25485-v2/update.xml?force=1
*** AUS:SVC Checker:checkForUpdates - sending request to: https://people.torproject.org/~boklm/tmp/bug_25485-v2/update.xml?force=1
*** AUS:SVC Checker:onLoad - request completed downloading document
*** AUS:SVC Checker:getUpdateURL - update URL: https://people.torproject.org/~boklm/tmp/bug_25485-v2/update.xml?force=1
*** AUS:SVC Checker:onLoad - number of updates available: 1
*** AUS:SVC getCanApplyUpdates - testing write access /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/update.test
*** AUS:SVC getCanApplyUpdates - able to apply updates
*** AUS:SVC Creating Downloader
*** AUS:SVC UpdateService:_downloadUpdate
*** AUS:SVC readStringFromFile - file doesn't exist: /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/updates/0/update.status
*** AUS:SVC readStatusFile - status: null, path: /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/updates/0/update.status
*** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist
*** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist
*** AUS:SVC Downloader:downloadUpdate - url: https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-8.0a9.1_signed_en-US.mar, path: /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/updates/0/update.mar, interval: 0
*** AUS:SVC Downloader:onStartRequest - original URI spec: https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-8.0a9.1_signed_en-US.mar, final URI spec: https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-8.0a9.1_signed_en-US.mar
*** AUS:SVC Downloader:onProgress - progress: 512/89917480
*** AUS:SVC Downloader:onProgress - progress: 524288/89917480
*** AUS:SVC Downloader:onProgress - progress: 884736/89917480
*** AUS:SVC Downloader:onProgress - progress: 1163264/89917480
*** AUS:SVC Downloader:onProgress - progress: 1294336/89917480
[...]
*** AUS:SVC Downloader:onProgress - progress: 89917480/89917480
*** AUS:SVC Downloader:onStopRequest - original URI spec: https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-8.0a9.1_signed_en-US.mar, final URI spec: https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-8.0a9.1_signed_en-US.mar, status: 0
*** AUS:SVC Downloader:onStopRequest - status: 0, current fail: 0, max fail: 10, retryTimeout: 2000
*** AUS:SVC Downloader:_verifyDownload called
*** AUS:SVC Downloader:_verifyDownload downloaded size == expected size.
*** AUS:SVC Downloader:_verifyDownload hashes match.
*** AUS:SVC Downloader:onStopRequest - setting state to: pending
*** AUS:SVC gCanStageUpdatesSession - testing write access /tb/tor-browser_en-US/Browser/update.test
*** AUS:SVC gCanStageUpdatesSession - testing write access /tb/tor-browser_en-US/update.test
*** AUS:SVC gCanStageUpdatesSession - able to stage updates
*** AUS:SVC Downloader:onStopRequest - attempting to stage update: Tor Browser 8.0a9.1
ERROR: Unknown signature algorithm ID 2.
ERROR: Unknown signature algorithm ID 2.
*** AUS:SVC readStatusFile - status: failed: 19, path: /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/updates/0/update.status
*** AUS:SVC handleFallbackToCompleteUpdate - install of complete or only one patch offered failed.
*** AUS:SVC UpdateManager:refreshUpdateStatus - Notifying observers that the update was staged. state: failed, status: failed: 19
*** AUS:SVC getCanApplyUpdates - testing write access /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/update.test
*** AUS:SVC getCanApplyUpdates - able to apply updates
*** AUS:SVC readStringFromFile - file doesn't exist: /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/updates/0/update.status
*** AUS:SVC readStatusFile - status: null, path: /tb/tor-browser_en-US/Browser/TorBrowser/UpdateInfo/updates/0/update.status
*** AUS:SVC Checker:getUpdateURL - update URL: https://people.torproject.org/~boklm/tmp/bug_25485-v2/update.xml
*** AUS:SVC Checker: checkForUpdates, force: false
*** AUS:SVC Checker:getUpdateURL - update URL: https://people.torproject.org/~boklm/tmp/bug_25485-v2/update.xml

Is that because version 7.5.6 doesn't know the key used to sign the alpha?

comment:54 in reply to:  53 Changed 3 months ago by boklm

Replying to boklm:

Is that because version 7.5.6 doesn't know the key used to sign the alpha?

Ah, that's because the 8.0a9.1 update was not made with MAR_OLD_FORMAT=1, so the error is expected.

comment:55 Changed 3 months ago by gk

I'll take the fix for 8.0a10. I guess we could verify this meanwhile by building an 8.0a9 just with this patch cherry-picked on top of it (i.e. with MAR_OLD_FORMAT=1) and then applying the result on top of 8.0a8?

comment:56 Changed 3 months ago by gk

Status: needs_reviewneeds_information

comment:57 Changed 3 months ago by boklm

Resolution: fixed
Status: needs_informationclosed

The build with this fix is starting correctly on Ubuntu 17.10, so it seems to fix the issue (even if we couldn't check that it also solve it in the first restart after the update).

Note: See TracTickets for help on using tickets.