Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tor-browser-bundle-bin: fix (noscript) extension startup #102622

Closed
wants to merge 2 commits into from

Conversation

xaverdh
Copy link
Contributor

@xaverdh xaverdh commented Nov 3, 2020

Motivation for this change

Fix the noscript part of #83096

Things done

Tested locally; this seems to fix the issue.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 3, 2020

This should fix the issue with noscript. Since its the only addon which got "lost" when firefox stopped sideloading from the installation directory, it probably won't do anything for other addons. So might not fix the linked issue fully.

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 3, 2020

(pushed a change, to also unmark as broken)

@joachifm
Copy link
Contributor

joachifm commented Nov 3, 2020

Has this been verified to not introduce impurities in the profile dir? If not, please ensure that the profile does not capture any Nix store paths in a way that may allow them to become stale.

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 3, 2020

Has this been verified to not introduce impurities in the profile dir? If not, please ensure that the profile does not capture any Nix store paths in a way that may allow them to become stale.

The only store paths I can see captured are from onboarding@mozilla.org, in the startup cache and such (so likely unrelated to this).

@yurkobb
Copy link
Contributor

yurkobb commented Nov 3, 2020

Thank you, NoScript is back for me at least for the initial start up after rm -fR ~/.local/share/tor-browser.

EDIT: after a restart, NoScript is gone again :(

@yurkobb
Copy link
Contributor

yurkobb commented Nov 3, 2020

If I comment out this line though, NoScript seems to persist across restarts:

rm -f "\$HOME/TorBrowser/Data/Browser/profile.default"/{addonStartup.json.lz4,compatibility.ini,extensions.ini,extensions.json}

And HTTPS Everywhere is also listed in about:addons.

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 4, 2020

Thank you, NoScript is back for me at least for the initial start up after rm -fR ~/.local/share/tor-browser.

EDIT: after a restart, NoScript is gone again :(

By gone, you mean gone from the UI or gone from about:addons ?
(for me its just not visible in the UI, but still there and working after restart)

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 4, 2020

If I comment out this line though, NoScript seems to persist across restarts:

rm -f "\$HOME/TorBrowser/Data/Browser/profile.default"/{addonStartup.json.lz4,compatibility.ini,extensions.ini,extensions.json}

Unfortunately that will capture store paths, if I read the comment there correctly.

@yurkobb
Copy link
Contributor

yurkobb commented Nov 4, 2020

Thank you, NoScript is back for me at least for the initial start up after rm -fR ~/.local/share/tor-browser.
EDIT: after a restart, NoScript is gone again :(

By gone, you mean gone from the UI or gone from about:addons ?
(for me its just not visible in the UI, but still there and working after restart)

In my second test just now of your PR, NoScript persisted after a restart and didn't disappear from the UI; in my previous test, JS was enabled in the Safest mode and NoScript was missing from the UI (I didn't check about:addons). Looks like it's the same behavior I had with the 9.x versions where addons disappeared unpredictably on restarts - sometimes they persisted, sometimes not.

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 4, 2020

In my second test just now of your PR, NoScript persisted after a restart and didn't disappear from the UI; in my previous test, JS was enabled in the Safest mode and NoScript was missing from the UI (I didn't check about:addons). Looks like it's the same behavior I had with the 9.x versions where addons disappeared unpredictably on restarts - sometimes they persisted, sometimes not.

Thats sad :-(
On my system at least I reliably have noscript up and working across restarts (when building from this pr). At least up to now.
But its doesn't show in the UI, no matter what I do.. maybe the upstream tor browser doesn't show it in the UI either? not sure..

@yurkobb
Copy link
Contributor

yurkobb commented Nov 4, 2020

I think I'll try to use it for a while; anyway, this is better than the original 10.x without NoScript at all. I'm not sure the state of things in 9.x are safe to call "unbroken", who knows what other weird bugs are hidden in there if the UI of the addon disappears.

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 7, 2020

Ok, I can now reproduce your issue. NoScript doesn't function from time to time..

@xaverdh xaverdh marked this pull request as draft November 7, 2020 08:49
@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 7, 2020

Ok, I went down a different route now, trying to force installation of NoScript via enterprise policies.

@yurkobb
Copy link
Contributor

yurkobb commented Nov 7, 2020

Thank you for investing time into this... I'm too unfamiliar with the architecture of the profile to understand what is going on. I was thinking though - is there a possibility of an altogether different way of using TBB at all, perhaps by using buildFHSUserEnv and run the unmodified TBB from torproject.org? This way it would self-manage its installation wherever we install it, per-user. What do you think?

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 7, 2020

Actually I had the same thought.
Especially since the issue here appears to not just be installation of the extension as I initially thought (even with enforcing it through policies NoScript appears broken after restarts).
I will look into using FHSUserEnv (or the more modern bubblewrap variant) eventually, but if someone wants to beat me to it, feel free to do so ;-)

@yurkobb
Copy link
Contributor

yurkobb commented Nov 7, 2020

I just got the original TBB running in nix-shell via a FHSUserEnv using this expression (I just copied the dependencies from the tor-browser-bundle-bin package, not sure if all of them are strictly required in this case); I will try running it for a while to see how it behaves.

{ pkgs ? import <nixpkgs> {} }:

(pkgs.buildFHSUserEnv {
  name = "tbb-env";
  targetPkgs = pkgs: (with pkgs;
    [ udev
      zlib
      alsaLib
      curl
      gnutar
      gtk3
      atk
      cairo
      dbus
      dbus-glib
      fontconfig
      freetype
      gdk-pixbuf
      glib
      gtk3
      xorg.libxcb
      xorg.libX11
      xorg.libXext
      xorg.libXrender
      xorg.libXt
      pango
      libpulseaudio
      apulse
      # Media support (implies audio support)
      ffmpeg_3

      gmp

      python27
    ]);
  runScript = "bash";
}).env

@xaverdh
Copy link
Contributor Author

xaverdh commented Nov 8, 2020

Thanks! Here we go: #103156

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants