[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20994 [Metrics/Onionoo]: invalid first_seen timestamp on bridges
#20994: invalid first_seen timestamp on bridges
-----------------------------+------------------------------
Reporter: cypherpunks | Owner: metrics-team
Type: defect | Status: needs_review
Priority: Medium | Milestone:
Component: Metrics/Onionoo | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------+------------------------------
Changes (by karsten):
* status: new => needs_review
Comment:
Okay, I'm more confident now that the fix suggested above is sane. Here's
why:
The `updatedNodes` data structure has the sole purpose of creating a set
of all fingerprints for `updateNodeDetailsStatuses()`, which is step 4 of
4 in the update process.
However, it doesn't make any sense to include a fingerprint which was
never seen in a consensus or bridge network status and for which we don't
have a `NodeStatus` instance. There's nothing that the non-existent
`NodeStatus` could contribute to the `DetailsStatus`, and there's no need
to create a mostly empty `NodeStatus` for a node that was never listed in
a consensus or bridge network status. In fact, we shouldn't even return
the node in a query, because the only proof of its existence comes from
self-published descriptors.
Regarding the `updatedNodes` set, we can as well go through `knownNodes`.
In fact, at one point we're adding all `knownNodes` to `updatedNodes`
anyway, so they contain the same entries. We can simply kick out
`updatedNodes` and use `knownNodes` in `updateNodeDetailsStatuses()`.
Here's what I think happened that led to this bug: We learned about a
bridge from a bridge server descriptor and created a mostly-empty
`NodeStatus` for it in `updateNodeDetailsStatuses()`, including a
`first_seen` date of 1970-01-01. At that time we didn't see this bridge
in any bridge network status. But some time later we did see it in a
status, which is how `last_seen` was updated. With the fix we wouldn't
have a `NodeStatus` until first seeing the bridge in a bridge network
status.
There, the good news is that this very likely fixes the issue. The bad
news is that I'll have to set up a temporary Onionoo instance and import
'''all''' bridge network statuses in order to get correct `first_seen`
dates for all bridges. I'll start doing that now, but it could easily
take days or even weeks. Transitioning to the new, correct data will be
fun, but there's still time to think about making that transition
smoother.
Please review
[https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-20994
my branch task-20994].
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20994#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs