#28591 closed defect (fixed)
Accept a future consensus for bootstrap
| Reported by: | teor | Owned by: | teor |
|---|---|---|---|
| Priority: | Medium | Milestone: | Tor: 0.3.5.x-final |
| Component: | Core Tor/Tor | Version: | |
| Severity: | Normal | Keywords: | bootstrap, clock-skew, tor-guard, usability, ux, s8-errors, 035-roadmap-subtask, 035-triaged-in-20180711, 035-backport-unreached |
| Cc: | iry, brade, mcs, intrigeri, torproject@… | Actual Points: | 0.5 |
| Parent ID: | #28018 | Points: | |
| Reviewer: | catalyst | Sponsor: |
Description
#24661 allows tor to bootstrap when the client's clock is ahead of the network by up to 1 day.
But clients can't bootstrap when the client's clock is behind the network by more than a few hours:
https://trac.torproject.org/projects/tor/ticket/24661#comment:18
Child Tickets
Change History (17)
comment:1 Changed 13 months ago by
| Status: | assigned → needs_review |
|---|
comment:2 Changed 12 months ago by
| Reviewer: | → catalyst |
|---|
comment:3 follow-up: 5 Changed 12 months ago by
| Status: | needs_review → needs_revision |
|---|
Thanks! Mostly looks good, but I haven't tested it yet. I left a minor comment on the pull request about a build failure that I get. When you fix that, I can try to do some manual tests. I can also try to fix it up myself later if you don't have the time.
comment:4 Changed 12 months ago by
| Sponsor: | → Sponsor8-can |
|---|
comment:5 Changed 12 months ago by
| Status: | needs_revision → needs_review |
|---|
Replying to catalyst:
Thanks! Mostly looks good, but I haven't tested it yet. I left a minor comment on the pull request about a build failure that I get. When you fix that, I can try to do some manual tests. I can also try to fix it up myself later if you don't have the time.
I fixed the build failure by making the code simpler.
comment:6 Changed 11 months ago by
| Status: | needs_review → merge_ready |
|---|
Thanks! Looks good. I did a little bit of manual testing with libfaketime.
comment:7 Changed 11 months ago by
| Actual Points: | → 0.5 |
|---|
comment:9 follow-up: 11 Changed 11 months ago by
| Milestone: | Tor: 0.4.0.x-final → Tor: 0.3.4.x-final |
|---|
I've squashed this as bug28591_035_squashed and merged it to master. We can consider for an 0.3.5 backport, but I am a little unsure about the complexity.
comment:10 Changed 11 months ago by
| Milestone: | Tor: 0.3.4.x-final → Tor: 0.3.5.x-final |
|---|
comment:11 Changed 11 months ago by
Replying to nickm:
I've squashed this as
bug28591_035_squashedand merged it to master. We can consider for an 0.3.5 backport, but I am a little unsure about the complexity.
I would not backport #28564 / commit a9c766c , consensus expiry code on relays has historically caused us a lot of issues.
If we backport #28591, let's do it in two stages:
comment:12 Changed 11 months ago by
| Keywords: | s8-bootstrap removed |
|---|---|
| Sponsor: | Sponsor8-can |
comment:13 Changed 10 months ago by
| Cc: | torproject@… added |
|---|
comment:14 Changed 9 months ago by
| Keywords: | 035-backport-unreached added |
|---|---|
| Resolution: | → fixed |
| Status: | merge_ready → closed |
This code is too complex to backport: people who need better reliability under clock skew will have to upgrade to 0.4.0 or later.
comment:15 follow-up: 16 Changed 9 months ago by
Not sure if it's correct to leave it in the Tor: 0.3.5.x-final milestone.
comment:16 Changed 9 months ago by
Replying to cypherpunks:
Not sure if it's correct to leave it in the
Tor: 0.3.5.x-finalmilestone.
It's tagged with 035-backport-unreached. When 0.3.5 closes, all its other open (unreached) backports will also be tagged with 035-backport-unreached.
Edit: open backports are tagged with 035-backport-unreached
comment:17 Changed 9 months ago by
Yes, but that means they don't have anything related to the Tor: 0.3.5.x-final milestone.
Here's the pull request:
https://github.com/torproject/tor/pull/551
The code is based on #24661 and maint-0.3.5. It also includes #28654. (I'm not sure if #28654 is a good idea, but it makes sense to be consistent.)