Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:23:32Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25605Add tests for Rust protover::compute_for_old_tor() and C functions it calls2020-06-13T15:23:32ZIsis LovecruftAdd tests for Rust protover::compute_for_old_tor() and C functions it callsIn https://trac.torproject.org/projects/tor/ticket/25386#comment:21, after changing/adding some tests, I noticed that `protover::compute_for_old_tor()` always returns an empty string, meaning that the version we parsed is new enough that...In https://trac.torproject.org/projects/tor/ticket/25386#comment:21, after changing/adding some tests, I noticed that `protover::compute_for_old_tor()` always returns an empty string, meaning that the version we parsed is new enough that the router should be reporting its own protocol versions. It's because the Rust code is calling the C version of `tor_version_as_new_as()`, which expects a _platform string_, not a version, so it gets to `tor_version_parse_platform()`, decides this is a "non-standard tor" and returns true early. So, in the top of the Rust function `protover::compute_for_old_tor()`, when we call `tor_version_as_new_as(version, FIRST_TOR_VERSION_TO_ADVERTISE_PROTOCOLS)` it says true, and we never reach the rest of the function.
The solution is to prepend `"Tor "` to each of the query strings in `protover::compute_for_old_tor()`.Tor: unspecified