[tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--------------------------------------+--------------------------------
 Reporter:  arthuredelstein           |          Owner:  JeremyRand
     Type:  defect                    |         Status:  needs_revision
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  TorBrowserTeam201912      |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:  gk                        |        Sponsor:
--------------------------------------+--------------------------------

Comment (by JeremyRand):

 Thanks for the review @gk.

 > 1) Looking at the `electrum-nmc` project there are a bunch of features
 that are conditional. However, there are no plans right now to offer
 conditional Namecoin features in Tor Browser nightly builds. Please remove
 all the complexity here and just take what we want to ship initially.
 >
 > 2) For the `certifi` config, see 1) above. There is no need to include
 the root certs conditionally.

 I'm okay with making this requested change.  However, please note that
 doing this will increase the maintenance burden on my end, because it's
 easier for me to maintain Electrum-NMC if the same rbm projects are used
 for both Namecoin's binaries and Tor's binaries.  (Namecoin isn't yet
 using rbm to build our official Electrum-NMC binaries, but these rbm
 projects were written with that goal in mind, and hopefully we will
 transition to using them in the foreseeable future.)  If needing to
 maintain two sets of rbm projects for Electrum-NMC is the cost of getting
 into Tor Browser, then I can deal with that, but it will have an impact on
 my maintenance costs.

 > 3) The build scripts for the dependencies seem to be quite complex given
 that they should just create a tarball of .py at the end if I see that
 right: you invoke first `sdist` to create what essentially is already a
 source tarball just to shuffle things around later on to create the source
 tarball in rbm-style which you actually use later on. Could we avoid one
 of those two steps here? Like, could we just do the Python source tarball
 creation here and use that one (maybe with some general, not per-project,
 post-processing later on when those sources are getting used)? If not,
 could we just zip up the necessary .py files ourselves avoiding the Python
 steps?

 The reason I didn't solely use the Python `sdist` functionality is that
 the tarballs it produces are nonreproducible, and there's an auditability
 benefit to having the outputs of those projects be reproducible (even
 though it shouldn't impact the final Tor Browser binaries).

 I'm honestly not certain if it's feasible to skip the `sdist`
 functionality and solely use rbm's tarball creation.  `sdist` can do
 interesting things that may be nontrivial to mimic on our own, but I don't
 know how many (if any) of the packages we're using actually use any of
 those interesting things.  Would you like me to attempt this approach and
 see how well it works?

 It would probably be feasible to simplify the amount of build code here by
 doing something similar to the `build_go_lib` template that's used for Go
 libraries.  Would this be something you'd like me to attempt prior to a
 Nightly merge?  (If it's not necessary for a Nightly merge, I will
 probably still do it at some point, since I like the `build_go_lib`
 structure and it seems like it would be helpful here.)

 > 4) If we stick to the Python `sdist` process I think it is not necessary
 to specify `--format=gztar` as this should be the default on Unix-like
 systems (which are the only systems we use for building).

 No objection here.

 > 5) I've not looked at later commits in depth yet but if 1)-4) affect
 them please fix those issues in them during that round of review as this
 is speeding up the whole process.

 Sorry, I wasn't able to parse this sentence with certainty (more pronouns
 than I can handle).  Am I correct in interpreting this as "issues 1-4
 should be fixed in 3fb39eeac9cb898245bc38f1444f48984a09a1a8, but issues
 1-4 should not be fixed in later commits until the later commits are
 reviewed"?

 Thanks again for the review!

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