Stop setting bridges running in networkstatus_getinfo_by_purpose()

A GETINFO controller function shouldn't modify vital data structures.

Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.

This bug was introduced in commit 74d05f4 in tor-0.2.0.13-alpha.

changed milestone to %Tor: 0.4.1.x-final

added code-correctness component::core tor/tor easy intro milestone::Tor: 0.4.1.x-final owner::neel points::1 priority::medium refactor resolution::fixed reviewer::ahf severity::normal status::closed type::defect labels

Replying to ffmancera from #tor-dev:

No, I am not working on this. It's a bug komlo and I discovered at the recent Tor meeting.

Trac:
Cc: N/A to ffmancera

What we need to do to fix this bug is to move the call that sets bridges running somewhere else, so that this function doesn't have any side effects.

This might mean that we need to make the call happen as a scheduled task, because none of the controller GETINFO code should change state.

Maybe isis will have an opinion on how best to fix this?

Trac:
Cc: ffmancera to ffmancera, isis

Trac:
Owner: N/A to neel
Status: new to assigned
Cc: ffmancera, isis to ffmancera, isis, neel

My PR is here: https://github.com/torproject/tor/pull/889

Setting as needs_review.

Trac:
Status: assigned to needs_review

Trac:
Reviewer: N/A to ahf

I think the code looks good, but I'm not marking it as ready for merge yet. I've just asked the other network team members about how we should review the exceptions file for practracker. I've also asked the current bridge auth administrator how they handle this currently.

I noticed that teor gave reviews to my PR. I have pushed the revisions. Still needs to pass CI, however.

Hi neel, thanks, but I wasn't finished with my review.

I have numbered the changes that we need to make.

Replying to ahf:

I think the code looks good, but I'm not marking it as ready for merge yet. I've just asked the other network team members about how we should review the exceptions file for practracker.

1. I think we can put most of the new flag-setting code in voteflags.c: https://github.com/torproject/tor/pull/889/files#r274725520

In fact, we might not even need a new callback:

I've also asked the current bridge auth administrator how they handle this currently.

I bet it just works for them, and they don't know how it works :-)

v3 (non-bridge) directory authorities update the Running flag when they vote.

But for bridges, the Running flag gets updated in the getinfo function.

2. For consistency, let's update the bridge Running flag in networkstatus_dump_bridge_status_to_file(), before calling networkstatus_getinfo_by_purpose().

Authorities also update the running flag in list_server_status_v1(), another control port function.

3. For consistency, let's stop updating the Running flag in list_server_status_v1(), and just let it be updated when the vote/bridge-status is written.

4. For each function we modify, let's update the function documentation.

5. Let's also update the dir-spec, to document the old and new behaviour. The first version with the new behaviour will be 0.4.1.1-alpha, let's put that in the spec.

I have made the changes.

The torspec PR is here: https://github.com/torproject/torspec/pull/76

I believe the changes had to be made in control-spec, not dir-spec.

Trac:
Milestone: Tor: unspecified to Tor: 0.4.1.x-final

There are two pull requests in this ticket: Code: https://github.com/torproject/tor/pull/889 Spec: https://github.com/torproject/torspec/pull/76

I think the spec change looks good and as far as I can tell you addressed the concerns teor had with the code.

Trac:
Status: needs_review to merge_ready

The code changes and the spec changes look like they do what they're supposed to do. Quick question, though: is this actually an improvement? We're making a GETINFO result less accurate. Maybe doing this on a timer would be more sensible? If so I'll merge this, then do another ticket to add a timer.

Replying to nickm:

The code changes and the spec changes look like they do what they're supposed to do. Quick question, though: is this actually an improvement? We're making a GETINFO result less accurate. Maybe doing this on a timer would be more sensible? If so I'll merge this, then do another ticket to add a timer.

Sure, I think that doing it on a timer is sensible.

Replying to teor:

Sure, I think that doing it on a timer is sensible.

I've opened #30301 (moved) for this.

Branches merged to tor master and to torspec.

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

closed

changed time estimate to 8h

mentioned in issue #30301 (moved)

moved to tpo/core/tor#24490 (closed)

mentioned in issue tpo/core/tor#30301 (closed)