Opened 3 years ago

Closed 3 years ago

#20828 closed defect (worksforme)

Should we provide a migration method from the old guard logic to the new one?

Reported by: nickm Owned by:
Priority: High Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-guard, triage-out-030-201612
Cc: Actual Points:
Parent ID: #20822 Points:
Reviewer: Sponsor:

Description

Our new (prop271) guard code stores guard state in a new way, and makes no effort to look at the old guard state. For clients who are upgrading, should we put more effort into keeping their pre-0.3.0 guards? We need to decide soon.

(I lean towards "no".)

Child Tickets

Change History (5)

comment:1 Changed 3 years ago by dgoulet

Keywords: tor-guard added

comment:2 Changed 3 years ago by teor

This provides a client upgrade distinguisher: when a client suddenly starts trying N new IP addresses, it has upgraded to 0.3.0.

Fortunately, we plan on adding ~130 new fallback directory mirrors in 0.2.9 and 0.3.0 (#18828), so the new guards would be somewhat hidden, at least every time the client consensus expires.

comment:3 Changed 3 years ago by asn

I would take a patch, but this seems like too much engineering effort right now. I'm also fine with 'no' here.

comment:4 Changed 3 years ago by dgoulet

Keywords: triage-out-030-201612 added
Milestone: Tor: 0.3.0.x-finalTor: unspecified

Triaged out on December 2016 from 030 to Unspecified.

comment:5 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.0.x-final
Resolution: worksforme
Status: newclosed
Note: See TracTickets for help on using tickets.