#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): > a) In gobtcd: Why is there build_go_lib_pre defined? What does that do? Building ncprop279 without it works perfectly fine for me. IIRC this is a historical relic that exists due to complexities involved in having Namecoin maintain a fork of btcd with minimal diff against upstream (meaning that a bunch of imports refer to upstream btcd's namespace). I think it's probably no longer needed because it was introduced before the `gobtcd`/`gobtcd2` split, and `gobtcd2` now has the same effect as this hack since it installs to upstream's namespace. I'll test to make sure that this hack is no longer needed, and remove it if testing confirms that it's okay to remove. > b) Why is gobtcd and gobtcd2 split? Is that because gobtcd depends on gobtcutil which depends on gobtcd2? How does the compilation of that work outside tor-browser-build as I can't imagine that this circular dependency is not an issue there as well? If you can't work around that (i.e. have only one gobtcd project) then please add a comment, probably in the gobtcd2 project, explaining the problem. `gobtcd` builds the `btcjson` and `rpcclient` subpackages of `btcd`. `gobtcd2` builds the `btcec`, `chaincfg`, `chaincfg/chainhash`, and `wire` subpackages of `btcd`. The former set depends on another project (probably `gobtcutil` as you say), and that project depends on the latter set. It's not a circular dependency in terms of Go packages (so it works fine outside of rbm since `go get` operates on the level of Go packages, not Git repos), but it is a circular dependency in terms of Git repos (meaning that it causes problems in rbm since rbm uses 1 project per Git repo). I'll add a comment explaining this. > c) gowinsvc is not needed, please remove it. No objection. > d) ncdns: os_go_lib_deps is empty, please remove it and the respective for-loop in the build script. No objection. > e) ncdns: +#mkdir -p /var/tmp/build etc. is commented out but not needed, please remove it. No objection. > f) ncdns: what is [snip] doing at that place in the build script as you are not building after it anymore? The same goes for +# Build as library. Good point, I think I forgot to remove that while I was removing the conditional support for building ncdns as an executable. I'll remove that. > g) ncdns: the goxlog dependency does not seem to be needed, please remove it. Interesting; this was definitely required when building ncdns as an executable with TLSA support enabled. I'll check to make sure it can be safely removed when building ncdns as a library with TLSA support disabled, and remove it if that still works. (I'll also fix that in Namecoin's version of the rbm scripts, where the conditional vars are still a thing.) > h) ncprop279: there is a bunch of comments in the build script which are not needed, starting with +#mkdir -p /var/tmp/build; please remove them. No idea how those got left in there; I'll remove them. > i) ncprop279: what does [snip] do? The `linux-x86_64` conditional is to handle the Go compiler putting binaries into a different folder depending on whether they're cross- compiled. In this case, `linux-i686` binaries are considered cross- compiled. I think the `ls` was left there by mistake; I'll remove that line. > j) +export CGO_ENABLED=[% c("var/cgo") %] <- no need for having that exported as cgo seems to be 0. Thus, you can remove all the cgo related things. IIRC the Go compiler defaults to CGO_ENABLED=1 in some cases, which I think includes linux targets in `tor-browser-build`. The intent of that line is to make sure cgo stays disabled even if the default would be to enable it. No objection to removing the variable though, since it will always be 0 here. I'll push an updated branch later today. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30558#comment:42> 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