[tor-bugs] #22640 [Metrics/metrics-lib]: Change encoding of microdescriptor digests in network status entries from hex to base64

[Tor Bug Tracker & Wiki]

#22640: Change encoding of microdescriptor digests in network status entries from
hex to base64
-------------------------------------+-------------------------------
     Reporter:  karsten              |      Owner:  metrics-team
         Type:  defect               |     Status:  new
     Priority:  Medium               |  Milestone:  metrics-lib 1.9.0
    Component:  Metrics/metrics-lib  |    Version:
     Severity:  Normal               |   Keywords:
Actual Points:                       |  Parent ID:
       Points:                       |   Reviewer:
      Sponsor:                       |
-------------------------------------+-------------------------------
 CollecTor's `ReferenceChecker` is acting up again, reporting tons of
 missing microdescriptors, basically all of them.  Today I found out why.

 Turns out that neither `NetworkStatusEntry#getMicrodescriptorDigests()`
 nor `NetworkStatusEntry#getMicrodescriptorDigestsSha256Base64()` returns
 base64-encoded digests but hex-encoded ones.  The former exists since
 1.0.0, the latter was added in 1.7.0 in an attempt to streamline digest
 method names, deprecating the former.

 Neither of the two methods says in its JavaDocs that it returns
 base64-encoded digests, though the latter indicates that in its method
 name.  The original digest string contained in votes and microdesc
 consensuses is base64-encoded, too.  All in all it seems like we should
 change both methods to return base64-encoded strings and document that.

 This issue is related to the bug we fixed in 1.8.0 where
 `Microdescriptor#getMicrodescriptorDigest()` and
 `Microdescriptor#getDigestSha256Base64()` return a hex string rather than
 a base64 string.  In that case we even claimed in the JavaDocs that we'd
 return a base64-encoded string, which we didn't.

 The current issue is not a regression, it's just an oversight of a very
 similar bug that was introduced far before 1.8.0 or even 1.7.0.  That's
 why I suggest to fix it in 1.9.0 next week and not put out a third patch
 release for 1.8.0 this weekend.  I can just ignore CollecTor's warnings
 for a few more days.

 I'll attach a branch in a minute.  That branch also prevents similar bugs
 in the future by changing `ParseHelper` method signatures to return `void`
 if we don't plan to use the result and add new methods for parsing,
 verifying, and converting to another encoding.

 I tested this branch in a local CollecTor instance and can confirm that it
 does silence the `ReferenceChecker`.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22640>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online