[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs