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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:  TorBrowserTeam201911      |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------------

Comment (by JeremyRand):

 Thanks for the feedback Georg.  I've just pushed a revised set of patches
 (same branch as before; Git commit hash
 `26c5593a9230e22b52b03917ad274b8ea08a70b5`) that I believe addresses your
 review so far.

 > Alas, I don't have time to review everything at once. My current plan is
 to go commit by commit and let you fix up things as we go. I hope this
 works for you.

 Yes, in fact that's better than reviewing everything at once, since it
 lets me start addressing feedback sooner.

 > I guess that hard-coding is done by taking the Tor Browser default
 values? One thing to keep in mind is that not every user is using 9150 as
 the SOCKS port. I don't know how hard it is to make this more dynamic but
 it would be nice if it were possible (but it's not necessary for a nightly
 inclusion).

 Doing this the "right way" will probably require patching Electrum-NMC;
 I'll put it on my to-do list.  That said, can you elaborate on what types
 of users will be using a non-default SOCKS IP/port?  The only cases I can
 think of are setups like Tails and Whonix, and those setups will need
 other changes to work with Namecoin because they use a control port filter
 that will interfere with StemNS.  I definitely want to support those use
 cases (if nothing else because Whonix is my daily driver OS), but I'm
 curious if there's another set of use cases where this matters that I'm
 not aware of.

 > Are you sure this is needed? We are applying a lot of other patches
 without requiring `patch` being explicitly installed (because it seems to
 come at least in newer OSes installed by default).

 Yes; removing that line causes the build to fail because `patch` isn't
 found.  Maybe `patch` is only installed by default in newer versions of
 Debian than what's used here.

 > Please remove those comments here and just include those projects when
 it is time.

 Done.

 > I think we can't require users just having `python3` available yet.
 Please add a check and somewhere so users get a notice when they need to
 install `python3`.

 Done.  At the same time I also now check if their `python3` is too old,
 and give them a notice for that case too.

 > Please add a `namecoin: 0` to all the other platforms given that you are
 not only checking for Namecoin support when dealing with Linux.

 Done.

 > 1) We try to make it possible to bisect issues in tor-browser-build in
 the sense that resulting builds are still running. It's hard sometimes and
 sometimes even not really possible, but that should be the goal anyways.
 With that in mind I think the commit I looked at above should be (to a
 large extend (that is without the changes in rbm.conf)) the *last* in your
 series of patches. Usually one is adding commits for all the projects and
 then in the final commit(s) one is "activating" those by getting them
 actually build once one sets the proper flags/or builds for the respective
 platforms/architectures. It would be nice if you could follow this general
 idea.

 Good point.  I've rearranged the order and grouping of commits to
 hopefully bring it closer to what you describe.  Let me know if this is an
 improvement, and whether there's anything remaining that I should do on
 this front.

 > 2) Please don't use the submodule approach you had in mind first and
 then later on discard it in favor of including all the needed projects
 directly. Just include those projects directly. This makes the patch set
 smaller, is easier to review, and is the right thing to do anyway.

 Done.

 Thanks for the review!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30558#comment:17>
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