Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4

The release series 0.3.0 through 0.3.4 are no longer supported, and we have encountered at least one bug (#27841 (moved)) caused by them lingering on the network.

We should have the authorities stop listing them in their votes. The patch here is simple enough -- we just edit dirserv_get_status_impl to reject everything newer than "0.3.0.0" and less new than "0.3.5.x" (for some well chosen "x").

But before we do this, we should take necessary steps to contact operators and let them know that they really really need to upgrade.

changed milestone to %Tor: 0.4.1.x-final

Trac:
Parent Ticket: #25882 (moved)

added 041-backport 042-can component::core tor/tor consider-backport-after-0422 consider-backport-after-authority-test milestone::Tor: 0.4.1.x-final owner::nickm parent::25882 priority::medium resolution::fixed reviewer::dgoulet reviewer::teor severity::normal status::closed tor-bridgeauth tor-dirauth type::enhancement labels

Should we add a torrc option that has a list of rejected versions (or version ranges)?

How often do we want to reject old versions like this?

So far, we've done it quite infrequently, through direct editing of dirserv_get_status_impl. I'd be fine asking the authority operators what they think of an option, but I think an option can be orthogonal to changing this value for now.

I started sending out reminders (you can see them on the network-health list), but many more remain.

Trac:
Status: new to accepted
Owner: N/A to nickm

I've made a branch ticket31549 with PR at https://github.com/torproject/tor/pull/1276 .

It is based on 041, in case we decide to backport.

Trac:
Status: accepted to needs_review
Keywords: 042-can deleted, 042-can 041-backport? added

Could we drop everything before 0.3.5 with the EOL of 0.2.9?

Replying to cypherpunks:

Could we drop everything before 0.3.5 with the EOL of 0.2.9?

Maybe. If we can convince enough 0.2.9 operators to upgrade,

Replying to nickm:

I've made a branch ticket31549 with PR at https://github.com/torproject/tor/pull/1276 .

I did a review, and requested some minor changes.

dgoulet also asked a question: https://github.com/torproject/tor/pull/1276/files#r319148111

It is based on 041, in case we decide to backport.

When do we want to make this change on the network?

At the moment:

• 3 authorities are on 0.4.1 and later.
• 1 authority is on 0.4.2.0-alpha-dev. https://consensus-health.torproject.org/#authorityversions

Here are the backport constraints:

• release 0.4.2.1-alpha: End September?
• finish test on moria1: mid to end September https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current

Here are the deployment requirements:

• backport to 0.4.1
• get majority of authorities on 0.4.1
• get a majority of authorities to upgrade to the point release containing the backport

So I think we can drop these relays by October, if we want to.

Trac:
Status: needs_review to needs_revision
Keywords: 042-can 041-backport? deleted, 042-can 041-backport consider-backport-after-authority-test consider-backport-after-0421 added

Trac:
Cc: N/A to dgoulet

Branch updated with fixup and squash commits.

I'm fine letting this change deploy "organically", letting authorities update on their own time, one by one. We can accelerate the process if we think we need to, though.

Trac:
Status: needs_revision to needs_review

Ok, I will backport on our normal schedule then.

Replying to teor:

Replying to cypherpunks:

Could we drop everything before 0.3.5 with the EOL of 0.2.9?

Maybe. If we can convince enough 0.2.9 operators to upgrade,

I think we could already now start the process of reaching out to them tbh. At this consensus hour, there are 777 relays representing ~6.13% of the network in bw weight. 4 months before EOL is definitely not too early to start doing that. I'll draft an email to try to start coordinating this.

Mark a number of current 0.4.2.x "defects" as "enhancements."

Trac:
Type: defect to enhancement

This change also affects the bridge authority.

Let's check how many bridges are on old versions, then decide if we want to:

• contact all the operators who are on old versions, or
• modify the patch to change the versions that the bridge authority allows.

Trac:
Status: needs_review to needs_revision

Trac:
Keywords: 042-can 041-backport consider-backport-after-authority-test consider-backport-after-0421 deleted, 042-can 041-backport consider-backport-after-authority-test consider-backport-after-0421 tor-dirauth tor-bridgeauth added

Replying to teor:

This change also affects the bridge authority.

Let's check how many bridges are on old versions, then decide if we want to:

• contact all the operators who are on old versions, or

Isn't this a bit difficult? ContactInfo are sanitized out of the bridge descriptors afaik?

Meaning, we would need to ask BridgeDB or Collector admin to basically compile a list for us and sekretly pass it down to someone to mass email operators... That is... interesting.

• modify the patch to change the versions that the bridge authority allows.

What I would do is make sure TB default bridges are all 035 >= (which is the majority of bridge traffic). But I would not treat differently bridges from relays. Not only those relays are EOL but some have bad TROVE issues so imo we shouldn't behave differently.

Replying to dgoulet:

Replying to teor:

This change also affects the bridge authority.

Let's check how many bridges are on old versions, then decide if we want to:

• contact all the operators who are on old versions, or

Isn't this a bit difficult? ContactInfo are sanitized out of the bridge descriptors afaik?

Meaning, we would need to ask BridgeDB or Collector admin to basically compile a list for us and sekretly pass it down to someone to mass email operators... That is... interesting.

Sure. No bridge operator emails then.

• modify the patch to change the versions that the bridge authority allows.

What I would do is make sure TB default bridges are all 035 >= (which is the majority of bridge traffic). But I would not treat differently bridges from relays. Not only those relays are EOL but some have bad TROVE issues so imo we shouldn't behave differently.

Ok, so I think there are a few tasks remaining for this ticket:

1. Work out how many bridges are on old versions rejected by this patch
2. Decide if we want this change to apply to the bridge authority at the same time as the directory authorities

And separately: 3. Check that the default bridges are on 0.3.5 or later

Marking as needs info, because we need to know how many bridges are on old versions, before we merge this patch.

Trac:
Status: needs_revision to needs_information