Opened 2 years ago

Closed 2 years ago

#21912 closed defect (fixed)

Deal with the deprecation of the `hardened` channel.

Reported by: yawning Owned by: yawning
Priority: High Milestone:
Component: Archived/Tor Browser Sandbox Version:
Severity: Normal Keywords:
Cc: gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Per: https://trac.torproject.org/projects/tor/ticket/20814#comment:11

The hardened channel for Tor Browser is going away. The sandbox will need updates for this.

Easy changes:

  • Make it impossible to install the hardened channel.
  • The selfrando specific "disable AESNI in NSS" workaround should apply to the alpha channel.

Release after the hardened removal:

  • Remove ASAN specific workarounds.
  • Purge the remnants of hardened except for the migration path (Can/should be done immediately if the migration path for sandboxed users is a reinstall).

How the actual migration from hardened to alpha is handled on the sandboxing end is currently an open question. The easy thing to do would be to force a reinstall, but people probably don't realize that a reinstall will obliterate all existing preferences and bookmarks. The more involved fix would be to modify the updater to handle channel migration.

Child Tickets

TicketStatusOwnerSummaryComponent
#21927closedyawningRemove the ability to install/update the hardened bundle.Archived/Tor Browser Sandbox
#21928closedtbb-teamForce a reinstall if an existing hardened bundle is present.Archived/Tor Browser Sandbox
#21929closedyawningRemove hardened/ASAN related code.Archived/Tor Browser Sandbox

Change History (6)

comment:1 Changed 2 years ago by gk

Cc: gk added

comment:2 Changed 2 years ago by yawning

Given the complexity of migrating users seamlessly, I'm going to opt for a forced reinstall, unless someone manages to convince me otherwise.

Rationale:

  • It's not immediately obvious to me how to detect that a channel switch has happened from the update metadata (https://wiki.mozilla.org/Software_Update:updates.xml_Format). This also applies to the bundle locale.
  • The sandboxed-tor-browser update code was not, and is not written to take into account things like channels changing, or locales disappearing.
  • It's cleaner in the long run.

I do not know what will happen when the existing sandboxed-tor-browser has a hardened bundle installed and it encounters the update at the deprecation point. My suspicion is that the update has a good chance of applying, but it will then fail to detect libasan.so and drop the user back to the config screen repeatedly.

There isn't anything I can do about this now, since code that's out there is code that's out there.

comment:3 Changed 2 years ago by gk

Yeah, sorry for that but it seems you me the way you go is not a bad one. FWIW: we'd need a tag with all changes that should make it into the alpha in about 30 hours from now on (April 13 1600 UTC).

comment:4 in reply to:  2 ; Changed 2 years ago by boklm

Replying to yawning:

Given the complexity of migrating users seamlessly, I'm going to opt for a forced reinstall, unless someone manages to convince me otherwise.

Rationale:

Yes, it is not possible to detect it from the update metadata. You can detect it by looking at the file Browser/defaults/pref/channel-prefs.js. The switch will be done with a mar file updating this file and the Browser/update-settings.ini file only.

  • The sandboxed-tor-browser update code was not, and is not written to take into account things like channels changing, or locales disappearing.
  • It's cleaner in the long run.

I do not know what will happen when the existing sandboxed-tor-browser has a hardened bundle installed and it encounters the update at the deprecation point. My suspicion is that the update has a good chance of applying, but it will then fail to detect libasan.so and drop the user back to the config screen repeatedly.

The update modifying the channel preferences files should apply correctly, but assuming the sandbox updater is not looking at those files to know the current channel, nothing else will happen and users will stay on the last hardened version.

There isn't anything I can do about this now, since code that's out there is code that's out there.

Yes it seems difficult to do something.

comment:5 in reply to:  4 Changed 2 years ago by yawning

Replying to boklm:

Replying to yawning:

Yes, it is not possible to detect it from the update metadata. You can detect it by looking at the file Browser/defaults/pref/channel-prefs.js. The switch will be done with a mar file updating this file and the Browser/update-settings.ini file only.

On a somewhat tangential note, it would be nice if the architecture, channel, and locale for the currently installed bundle was stored in a consistent location across all releases, in a format that is easy to parse (and no, "Javascript Mozilla prefs" is not easy to parse).

The update modifying the channel preferences files should apply correctly, but assuming the sandbox updater is not looking at those files to know the current channel, nothing else will happen and users will stay on the last hardened version.

Ah ok. That may be less bad than "everything breaks".

comment:6 Changed 2 years ago by yawning

Resolution: fixed
Status: newclosed

Ok, I think this is done. Sorry I couldn't think of a good way to handle the transition beyond "make them reinstall if they're running an up to date sandboxed-tor-browser".

Note: See TracTickets for help on using tickets.