[tor-bugs] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

[Tor Bug Tracker & Wiki]

#31823: HSv3 descriptor support in stem [encoding]
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  atagar
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Stem                        |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs scaling onionbalance          |  Actual Points:  2
  network-team-roadmap-september tor-spec        |
Parent ID:  #26768                               |         Points:  5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:3 atagar]:
 > Hi asn, swapping our tor-dev@ discussion here as requested.
 >
 > > What is your plan with the hsv3 branch? Should I start reviewing your
 changes already, or give you more time to do more?
 >
 > Please give me another week. Ball's in my court, I'll let ya know once
 it's ready.
 >

 Sounds good! Have fun! I will be working on other things in the meanwhile!

 > > My only feedback so far is that the python2 port commits have broken
 python3 for me (particularly the ed25519 blinding implementation).
 >
 > Gotcha. For the moment tests pass with both python2 and python3 but I
 still break them occasionally as I work. If you have python3 issues with
 the final result please let me know and I'll address them.
 >

 Great! FWIW I use Python 3.7.4+ and the `descriptor.hidden_service_v3`
 unittest fails for me in `deba20b1`.

 > > Would it be egregious to provide hsv3 support only for python3 users
 so that we can use python3 features as we wish?
 >
 > This is actually a particularly interesting question right now. Here's
 my plans...
 >
 > * PSF plans to [https://pythonclock.org/ drop Python 2.x support in
 January 2020] and Stem will do the same.
 >

 Hmm, if we drop support for python2 in 3 months, wouldn't it be OK to
 write this feature in Python3? I imagine that the feature will be
 finalized in December or so, given bugfixes and stuff. So this leaves us
 about a month or even less. We could even delay shipping it in a release
 before January if needed (and I can work on Onionbalance by using
 unofficial branches).

 The reasons I suggested  doing Python3-only is:

 - The main reason for me is we won't need to spend time hunting down bugs
 and incompatibilities in Python2. A non-trivial part of your changes are
 Python2 compatibility improvements, and these usually take time to fix
 (and find).
 - We will be able to use nice python3 methods like `to_bytes()`,
 `fromhex()` and `hex()`.
 - We don't need to worry about str <-> bytes <-> unicode compatibility
 between python2 and python3
 - We might be able to make stronger assumptions on the crypto libraries
 being present.
 - We won't need to fix the ed25519 python3 code which is hairy crypto
 code.

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