clock_skew_warning should be a bootstrap event

Currently clock_skew_warning() doesn't log anything easily visible to Tor Launcher. (It does a LOG_WARN but that's not enough to produce a failure dialog.)

When we get a trusted clock skew indication, we should make sure to report it as a bootstrap problem, so Tor Launcher's existing logic will detect it as a fatal error.

changed milestone to %Tor: 0.3.2.x-final

added bootstrap clock-skew component::core tor/tor milestone::Tor: 0.3.2.x-final owner::catalyst parent::23508 priority::high resolution::implemented severity::major status::closed type::defect usability ux labels

Really? Shouldn't the controller be listening for CLOCK_SKEW STATUS_GENERAL events, and reacting to them as a problem that it needs to bring to the user's attention?

Replying to arma:

Really? Shouldn't the controller be listening for CLOCK_SKEW STATUS_GENERAL events, and reacting to them as a problem that it needs to bring to the user's attention? That's one possibility, but the Tor Launcher devs have rejected that before for various reasons, and this is the best way to get a substantial usability improvement with the existing Tor Launcher.

Replying to catalyst:

That's one possibility, but the Tor Launcher devs have rejected that before for various reasons, and this is the best way to get a substantial usability improvement with the existing Tor Launcher.

Hmm. I don't think we rejected that idea. When Kathy and I experimented with it, we found that in our testing it did not solve the problem. Specifically, a CLOCK_SKEW event was generated before Tor Launcher had established its control port connection, so Tor Launcher did not see it. But as I write this I wonder if our testing was flawed, because if we start tor with DisableNetwork=1, then connect to the control port, then monitor STATUS_GENERAL events, it seems like we would see the first CLOCK_SKEW event (but I know very little about tor internals).

Anyway, somewhere I have experimental code that monitors CLOCK_SKEW events... so if that is the Right Thing To Do we can add it to Tor Launcher.

Trac:
Cc: N/A to brade, mcs

Replying to mcs:

Specifically, a CLOCK_SKEW event was generated before Tor Launcher had established its control port connection, so Tor Launcher did not see it. I think this happens sometimes when there's an existing cached consensus. Otherwise, I'm able to see the CLOCK_SKEW events when making a manual controller connection.

Trac:
Parent: N/A to #23508 (moved)

Trac:
Milestone: N/A to Tor: 0.3.2.x-final

Proposed patches in https://oniongit.eu/catalyst/tor/merge_requests/2

This fixes several of the bootstrap stalling behaviors where the client's clock is behind the network's time. (I think these are mainly the stalls at 25% and 40%.)

Trac:
Status: assigned to needs_review

Trac:
Keywords: bootstrap usability ux deleted, bootstrap clock-skew usability ux added

This looks fine to me, except for some minor function documentation issues.

Trac:
Status: needs_review to needs_revision

Updated the merge request with function documentation fixes, along with a changes file.

Trac:
Status: needs_revision to needs_review

It would probably be good to backport this so it can get into deployed versions of Tor Browser.

Merged!

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

I'm leaning towards no-backport; it's very close to a new feature in my book, and we should have 0.3.2.1-alpha out some time next week

(but if you disagree, please reopen and put it in needs_review for 0.3.1?)

closed

moved to tpo/core/tor#23506 (closed)