Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
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)Activity
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.
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)
#26589 (moved) is a duplicate.
Trac:
Keywords: N/A deleted, TorBrowserTeam201806 added
Priority: High to Very High
It seems that the issue is that
libgdk-3.so.0on Ubuntu is linked tolibmirclient.so.9, which is linked to a newer version oflibstdc++.so.6than 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 tolibmirclient.so.9. However this will increase the complexity, build time, and size of our bundles. - building and shipping a
libmirclient.so.9that is linked to our version oflibstdc++.so.6.
I think a better option might be to avoid having our version of
libstdc++.so.6inLD_LIBRARY_PATHwhen the version installed on the system is newer. Maybe thestart-tor-browserscript could detect which version oflibstdc++.so.6is available and only add our version toLD_LIBRARY_PATHwhen needed.- building and shipping a
-
Replying to gk:
Do we actually still need to ship that lib? I think we need to ship
libstdc++.so.6for the systems where the installed version is too old. As we are building using gcc 6.4.0, it seems our binaries will requireCXXABI_1.3.10added with gcc 6.1.0: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.htmlSome 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)
For what it's worth, this also is the root cause of #20866 (moved).
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 installedgccversion with the bundled Tor Browser version6.4.0. If the installed version is more recent, we remove the bundledlibstdc++.so.6fromBrowser/TorBrowser/Tor, which removes it fromLD_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.11and 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.10which tells us the same thing and instead of comparing the version strings, we can compare this but I thought the
gccversion is more direct.(As indicated in comment:14, we should consider using
rpathas discussed in #13373 (moved) but I am not focusing on that for now.)Trac:
Status: reopened to needs_revisionI 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.
-
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 installedgccversion with the bundled Tor Browser version6.4.0. If the installed version is more recent, we remove the bundledlibstdc++.so.6fromBrowser/TorBrowser/Tor, which removes it fromLD_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.
Trac:
Status: needs_review to needs_revision -
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 thereadelfoutput 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-browserfails then we know that we need to add our libstdc++ toLD_LIBRARY_PATH. -
Replying to Hello71:
what's wrong with rpath?
How would it help with this issue? I think using rpath instead of
LD_LIBRARY_PATHto use our libstdc++ library does not remove the issue that our libstdc++ can be too old forlibgdk-3.so.0or other installed libraries on some systems. 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 thereadelfoutput 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-browserfails then we know that we need to add our libstdc++ toLD_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_PATHto use our libstdc++ library does not remove the issue that our libstdc++ can be too old forlibgdk-3.so.0or 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.
-
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 thereadelfoutput 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-browserfails then we know that we need to add our libstdc++ toLD_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 filelibstdc++-v3/config/abi/pre/gnu.verfrom gcc sources: https://github.com/gcc-mirror/gcc/blob/gcc-6_4_0-release/libstdc%2B%2B-v3/config/abi/pre/gnu.ver#L1869It 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.6toLD_LIBRARY_PATH.So we could run this small program from
start-tor-browserto check if the system provides a recentlibstdc++.so.6, and only if it fails add our version toLD_LIBRARY_PATH. 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
Libdirectory to make it easier to deal withLD_LIBRARY_PATH. Let me know if you prefer another way. Tested on Ubuntu 16.04.Trac:
Status: needs_revision to needs_review-
Replying to sukhbir:
I decided to move the bundled libstdc++.so.6 to an additional
Libdirectory to make it easier to deal withLD_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. Replying to boklm:
Replying to sukhbir:
I decided to move the bundled libstdc++.so.6 to an additional
Libdirectory to make it easier to deal withLD_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.-
I think we could add a comment in
projects/firefox/abicheck.ccmentioning this ticket, and explaining that we found that this program is requiringGLIBCXX_3.4.22, which make it useful to check that the required version of libstdc++ is available.Otherwise the changes look good to me.
Trac:
Status: needs_review to needs_revision Branch with the review changes (comments in
abicheck.ccand updated directory name):https://github.com/azadi/tor-browser-build-1/tree/bug-25485-rev2
Trac:
Status: needs_revision to needs_review-
Replying to sukhbir:
Branch with the review changes (comments in
abicheck.ccand updated directory name):https://github.com/azadi/tor-browser-build-1/tree/bug-25485-rev2
Thanks! I pushed this to master as commit
6a89049c0d1200302a59f74e71151466ddae5582.Trac:
Resolution: N/A to fixed
Status: needs_review to closed -
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 thelibstdc++from the old location and adding it to the new one there is the risk that Tor Browser won't start anymore asLD_LIBRARY_PATHis still pointing to the old one. -
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_PATHin the same way as the start script, during the update process, before restarting the browser.Trac:
Status: closed to reopened
Resolution: fixed to N/A -
Note that the patch broke our nightly builds for Linux as well (see: #27101 (moved)).
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_PATHin 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.
-
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 (moved) so it is not clear if it is better.
I am wondering if we could update
LD_LIBRARY_PATHin 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_PATHin a script named firefox sounds like a good thing to try. 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?
-
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.
-
I pushed in branch
bug_25485_v2a patch that is renamingfirefoxtofirefox.real, and adding a wrapper script asfirefoxthat is settingLD_LIBRARY_PATH: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754A 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.
-
The patch in branch
bug_25485_v3is fixing the permissions onfirefox: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754I 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
Trac:
Status: reopened to needs_review
Keywords: TorBrowserTeam201808 deleted, TorBrowserTeam201808R added -
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.
-
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%"); -
Replying to boklm:
The patch in branch
bug_25485_v3is fixing the permissions onfirefox: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754I 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_file21: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.
-
Replying to gk:
Replying to boklm:
The patch in branch
bug_25485_v3is fixing the permissions onfirefox: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25485_v2&id=82ab87b6742b4cc5e245739231887cbe51a59754I 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_file21: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-nightlyas the version number. So I did a new build with the same patch, but building an alpha, with version number8.0a9.1: https://people.torproject.org/~boklm/tmp/bug_25485-v2/ -
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-nightlyas the version number. So I did a new build with the same patch, but building an alpha, with version number8.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.