[tor-bugs] #21449 [Core Tor/Tor]: Make tor version parsing and version spec consistent
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Feb 14 01:11:47 UTC 2017
#21449: Make tor version parsing and version spec consistent
------------------------------+------------------------------
Reporter: teor | Owner:
Type: defect | Status: new
Priority: Medium | Milestone: Tor: unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: tor-spec
Actual Points: | Parent ID:
Points: 2 | Reviewer:
Sponsor: |
------------------------------+------------------------------
In tor_version_compare, the git logic is a bit weird, because git tags are
hashes: the ordering we apply isn't their true order. So the function
comment should probably become:
{{{
/** Compare two tor versions; Return <0 if a < b; 0 if a ==b, >0 if a >
* b. Git tags are sorted by length, then value. */
}}}
But this doesn't match version-spec.txt:
{{{
The EXTRA_INFO is also purely informational, often containing information
about the SCM commit this version came from. It is surrounded by
parentheses
and can't contain whitespace. Unlike the STATUS_TAG this never impacts the
way
that versions should be compared.
}}}
We should try to ignore the git tag, or at least be very careful how we
compare it. Due to bugs like #20492, the following versions are
equivalent:
{{{
Tor 0.2.9.9 (git-56788a2489127072)
Tor 0.2.9.9
}}}
(But these are not equivalent to any other git tag on Tor 0.2.9.9, which
should never happen anyway.)
This is important when we try to exclude versions, like in #20509, because
we need to exclude the version with and without the git tag.
This fix might require a new consensus method.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21449>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list