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 Launcher 0.3.0 #352

Merged
merged 63 commits into from
Sep 14, 2018
Merged

Tor Browser Launcher 0.3.0 #352

merged 63 commits into from
Sep 14, 2018

Conversation

micahflee
Copy link
Collaborator

No description provided.

intrigeri and others added 30 commits January 29, 2018 08:24
…tion.

We already allow the main browser profile to do that but with e10s
plugin-container now needs it as well.
…m signals.

With e10s Firefox does not need to ptrace itself anymore but instead it needs
to ptrace and kill its child plugin-container processes.
…ent Firefox process.

We already allow Firefox to send term signals to plugin-container;
this is the receiving counterpart.

This requires giving the Firefox profile a proper name (torbrowser_firefox)
because this:

  signal (receive) set=("term") peer=/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox

… does not work.

Note to package maintainers
===========================

(This should probably be copied to the release notes.)

Due to the profile renaming, upgrading the
/etc/apparmor.d/torbrowser.Browser.firefox file requires special care. The best
option is probably to strongly recommend users to reboot their system after
this upgrade.

Other options I can think of have unacceptable consequences:

 - if we unload the old profile from the kernel, we will leave any already
   running Tor Browser's Firefox executable unconfined, which is an unacceptable
   violation of the user's security expectations;

 - if we don't unload the old profile from the kernel, surprising behaviour will
   happen such as:

    - any already running Tor Browser's Firefox executable will be left confined
      under the old profile which won't play well with new rules that have
      peer=torbrowser_firefox;
    - unpredictable behavior when a new Tor Browser is started, because two
      profiles matching the Tor Browser's Firefox executable are loaded.
So far we allowed it to do everything in there except a link operation, so let's
be consistent.
We don't currently allow access to the audio subsystem; let's not let AppArmor
spam the logs about it.
This will allow us to handle upgrades more nicely in the future,
e.g. when the executable path changes. Besides, this makes the output of
aa-status and logs much easier to grasp.

Note to packagers: exactly as for the similar change applied to the Tor
Browser's Firefox profile, please consider recommending users to reboot their
system after the upgrade that applies this change.
This fixes support for obfs4 and obfs3.

meek and fte require vastly more extended permissions and thus dedicated
child profiles.
This matches how recent dh-apparmor behaves.
Updated the French translation!
micahflee and others added 26 commits March 23, 2018 15:42
…tion fails, it saves a backup. And it uses gpg2 to refresh the keyring instead of gpg1, which did nothing.
…of-date and I use systemwide packages for deps
…compiled.

Otherwise, Tor Browser 8.0a9 crashes when clicking "Save Page As".
At this point it seems unlikely that the develop branch will be released
before Tor Browser 8.0 so here we go, let's get ready.

Note that I could have written firefox{,.real} instead, to support both Tor
Browser 7.5 and 8.0, but then we would have to open the profile more broadly so
the new shell wrapper installed as "firefox" by Tor Browser 8.0a10 can do its
job. This does not seem worth the hassle and will be fine as long as this new
torbrowser-launcher is released approximately at the same time as, or after, Tor
Browser 8.
@micahflee micahflee merged commit d6d0158 into master Sep 14, 2018
@intrigeri
Copy link
Collaborator

I'm not sure I understand what's expected from me. Is it a post-release code review of this PR?

@micahflee
Copy link
Collaborator Author

Oh sorry. I just meant to confirm that #323 is working for you now. It appeared to be working when I tested my fix, but since you opened the issue I wanted to make sure it worked for you too.

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