Opened 3 weeks ago

Last modified 3 days ago

#26514 new defect

intermittent updater failures on Win64 (Error 19)

Reported by: mcs Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201807
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


When testing updates from Tor Browser 8.0a8 (ESR52) to the 8.0a9 release candidate (ESR60), Kathy and I encountered a failure when trying to update a Win64 browser that was using an obfs4 transport. The error was 19 (CERT_VERIFY_ERROR). We cannot reproduce this error on other platforms, and the mar file signature does in fact seem to be correct.

When testing with the same mar file and running updater.exe manually via a CMD shell, we saw the same error. However, after several attempts the update succeeded. It seems to fail about 4/5 of the time. Georg pointed out that this sounds a lot like a problem that was reported on tor-talk a earlier this year:

Note that this is a bug in our ESR52-based Tor Browser; we will need to determine if the bug still exists in an ESR60-based browser (and look for the cause).

Child Tickets

Change History (6)

comment:1 Changed 3 weeks ago by cypherpunks

Oh shit! It happens exactly 4 times and succeeds then. The only difference in logs is:

AUS:SVC readStatusFile - status: succeeded, path: \Tor Browser\Browser\TorBrowser\UpdateInfo\updates\0\update.status

comment:2 Changed 3 weeks ago by gk

Keywords: TorBrowserTeam201806 added
Priority: MediumHigh

comment:3 Changed 2 weeks ago by gk mentions this seems to be a race condition as this is not visible on slower machines.

comment:4 Changed 2 weeks ago by gk

Priority: HighVery High

comment:5 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201807 added; TorBrowserTeam201806 removed

Moving first batch of tickets to July 2018

comment:6 Changed 3 days ago by mcs

So far, after many attempts, we have not reproduced this bug in an ESR60-based build. However, since it seems to be timing related, maybe we are just getting lucky (that no failures occur).

Investigating the failures with the ESR52-based Tor Browser, we found that it is easy to reproduce in an optimized build. But we found that we cannot reproduce the problem after adding some logging to the libmar code. We are now going to be smarter about the logging, e.g., we will not execute any additional code (and especially we will not log anything) until after an error occurs within libmar's signature verification code.

Note: See TracTickets for help on using tickets.