This repository has been archived by the owner on Dec 11, 2019. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reverse order in which we read tor control port and auth cookie.
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
- Loading branch information