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