[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 gk):

 Replying to [comment:28 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.

 Yes, I can see that point. Let me explain you as well where we are coming
 from: this ticket is not about "getting NameCoin into Tor Browser" in the
 sense that it decides whether to ship this feature in actual releases or
 not. It's about testing optional NameCoin support on one platform in
 nightly builds for those that are interested.

 However, including the Namecoin patches into `tor-browser-build` has costs
 far beyond just affecting a particular platform on the nightly series as
 it increases the general complexity of the `master` branch considerably.
 This is okay, but we should try to minimize that complexity, hence my
 request.

 That said, in case this experiment is successful and we indeed think about
 shipping Namecoin support to users then we'll maintain it in our repo
 ourselves like we do for all the other projects, too. Thus, it's not that
 you are stuck with maintaining two things.

 > > 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).

 Non-reproducible in what way?

 > 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?

 Please do.

 > 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.)

 No, that's not needed. Right now we don't have much Python code in our
 projects, thus I think it's not worthwhile to spend time on that at the
 moment. Maybe that would change if we decided to integrate Namecoin beyond
 the nightly testing we plan to do, but that would still be at some point
 in the future which we don't need to worry about right now.

 > > 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"?

 I meant if issues 1)-4) affect later commits please fix those commits up
 as well while you are addressing this round of feedback.

 > Thanks again for the review!

 No worries. Thanks for your patience and the review delay.

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