#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs