TorConnect: Move to the Start stage when a bootstrap fails due to a TorProvider initialisation error

Merge Info

Issues

Resolves

• #43636 (closed)

Related

Merging

Target Branches

• tor-browser - !fixups to tor-browser-specific commits, new features, security backports
• base-browser and mullvad-browser - !fixups to base-browser-specific commits, new features to be shared with mullvad-browser, and security backports
  • ⚠️ IMPORTANT: Please list the base-browser-specific commits which need to be cherry-picked to the base-browser and mullvad-browser branches here

Target Channels

• Alpha: esr128-14.5
• Stable: esr128-14.0
• Legacy: esr115-13.5

Backporting

Timeline

• No Backport (preferred): patchset for the next major stable
• Immediate: patchset needed as soon as possible (fixes CVEs, 0-days, etc)
• Next Minor Stable Release: patchset that needs to be verified in nightly before backport
• Eventually: patchset that needs to be verified in alpha before backport

(Optional) Justification

• Security update: patchset contains a security fix (be sure to select the correct item in Timeline)
• Censorship event: patchset enables censorship circumvention
• Critical bug-fix: patchset fixes a bug in core-functionality
• Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
• Sponsor required: patchset required for sponsor
• Localization: typos and other localization changes that should be also in the release branch
• Other: please explain

Upstream

• Patchset is a candidate for uplift to Firefox
• Patchset is a backport from Firefox
  • Bugzilla link:
  • Upstream commit:

Issue Tracking

• Link resolved issues with appropriate Release Prep issue for changelog generation

Review

Request Reviewer

• Request review from an applications developer depending on modified system:
  • NOTE: if the MR modifies multiple areas, please /cc all the relevant reviewers (since Gitlab only allows 1 reviewer)
  • accessibility : henry
  • android : clairehurst, dan
  • build system : boklm
  • ci/cd: brizental, henry
  • extensions : ma1
  • firefox internals (XUL/JS/XPCOM) : jwilde, ma1
  • fonts : pierov
  • frontend (implementation) : henry
  • frontend (review) : donuts, morgan
  • localization : henry, pierov
  • macOS : clairehurst, dan
  • nightly builds : boklm
  • rebases/release-prep : brizental, clairehurst, dan, ma1, pierov, morgan
  • security : jwilde, ma1
  • signing : boklm, morgan
  • updater : pierov
  • windows : jwilde, morgan
  • misc/other : pierov, morgan

Change Description

For TorProvider, we distinguish between bootstrap errors and initialisation errors with TorBootstrapError and TorProvoderInitError.

For TorConnect, we no longer assume that TorBootstrapRequest.onbootstraperror will receive a BootstrapError type. Instead we use the new error classes to adjust our response. In particular, we move to Start stage if we get TorProviderInitError and we move through the connect assist stages if we get TorBootstrapError. Otherwise we move to the FinalError stage.

In these areas I was tempted to do even more cleanup, but I want this to go into stable so I kept it minimal.

How Tested

Tested still works as expected with the various censorship levels.

Also made TorProvider throw the TorBootstrapError to ensure this works when not using censorship simulation.

And to check that this resolves the bug:

1. Open dev build of Tor Browser.
2. Switch on "connect automatically".
3. Perform a successful bootstrap.
4. Close the dev build instance.
5. Open another instance of Tor Browser.
6. Re-open the dev build of Tor Browser at the same time.

The automatic bootstrap attempt fails but we return to the "Start" stage. If you then close the other instance and restart tor in the dev build it will stay in the "Start" stage.