Add post by Jeremy "Porting Namecoin in Tor Browser to macOS" #579
Conversation
| tags: [News] | ||
| --- | ||
|
|
||
| Hot on the heels of [porting Namecoin in Tor Browser to Windows]({{ "/2020/08/28/porting-namecoin-in-tor-browser-to-windows.html" | relative_url }}), it was time to do the final remaining desktop OS, macOS. This one was always going to present a challenge in the QA testing department, because I don't own any macOS devices. On the other hand, I fully expected that the amount of code written for macOS support was going to be pretty minimal; in fact I expected that other than tweaking a few constants, macOS support was likely to be a subset of the code needed for Windows support. But of course, our friend Murphy wasn't going to let that assumption stand. |
There was a problem hiding this comment.
I fully expected that the amount of code written for macOS support was going to be pretty minimal
I fully expected the amount of code written for macOS support to be pretty minimal
There was a problem hiding this comment.
This suggestion erases the future-ish tense for "written", so I'd prefer not to make this change.
There was a problem hiding this comment.
I understand. In that case, how about "I fully expected that the amount of code written for macOS support would be going to be pretty minimal"?
| tags: [News] | ||
| --- | ||
|
|
||
| Hot on the heels of [porting Namecoin in Tor Browser to Windows]({{ "/2020/08/28/porting-namecoin-in-tor-browser-to-windows.html" | relative_url }}), it was time to do the final remaining desktop OS, macOS. This one was always going to present a challenge in the QA testing department, because I don't own any macOS devices. On the other hand, I fully expected that the amount of code written for macOS support was going to be pretty minimal; in fact I expected that other than tweaking a few constants, macOS support was likely to be a subset of the code needed for Windows support. But of course, our friend Murphy wasn't going to let that assumption stand. |
There was a problem hiding this comment.
in fact I expected
in fact, I expected
| tags: [News] | ||
| --- | ||
|
|
||
| Hot on the heels of [porting Namecoin in Tor Browser to Windows]({{ "/2020/08/28/porting-namecoin-in-tor-browser-to-windows.html" | relative_url }}), it was time to do the final remaining desktop OS, macOS. This one was always going to present a challenge in the QA testing department, because I don't own any macOS devices. On the other hand, I fully expected that the amount of code written for macOS support was going to be pretty minimal; in fact I expected that other than tweaking a few constants, macOS support was likely to be a subset of the code needed for Windows support. But of course, our friend Murphy wasn't going to let that assumption stand. |
| tags: [News] | ||
| --- | ||
|
|
||
| Hot on the heels of [porting Namecoin in Tor Browser to Windows]({{ "/2020/08/28/porting-namecoin-in-tor-browser-to-windows.html" | relative_url }}), it was time to do the final remaining desktop OS, macOS. This one was always going to present a challenge in the QA testing department, because I don't own any macOS devices. On the other hand, I fully expected that the amount of code written for macOS support was going to be pretty minimal; in fact I expected that other than tweaking a few constants, macOS support was likely to be a subset of the code needed for Windows support. But of course, our friend Murphy wasn't going to let that assumption stand. |
There was a problem hiding this comment.
our friend Murphy wasn't going to let that assumption stand.
our friend Mr. Murphy wasn't going to let that assumption stand.
There was a problem hiding this comment.
I dislike titles, so I'm not going to add Mr. here.
There was a problem hiding this comment.
I do think it should be indicated that it's a family name and not a given name, but since I don't see any way to do that without honorifics, I won't insist on it.
|
|
||
| ## Initial Attempt | ||
|
|
||
| As a first try, I added the Electrum-NMC, ncprop279, and StemNS dependencies (with their config files) to the `tor-browser` rbm project, and added the missing lines in Tor Launcher for determining the paths of Electrum-NMC and StemNS on macOS. Then I fliped the `var/namecoin` switch for macOS in `tor-browser-build`, and started up a build job. In order to build without errors, I then needed to make some slight edits to the build scripts of some of the Go projects that `ncprop279` depends on, mostly related to cgo edge cases. |
There was a problem hiding this comment.
(with their config files)
, and their config files,
There was a problem hiding this comment.
Doesn't really fit my style; I prefer a parenthetical here.
|
|
||
| ## What is this external user data craziness? | ||
|
|
||
| It turns out that Tor Browser for macOS does something very different from Tor Browser for GNU/Linux and Windows. On macOS, the user data directory is stored separately from the application executable code. To make matters worse, on macOS there is no way to supply "default" contents for the user data directory. In fact, in order to set the default bookmarks for Firefox, Tor Browser on macOS does some kind of witchcraft involving stuffing the bookmarks file inside one of the Firefox application archives, such that when Firefox eventually creates a fresh profile, the bookmarks end up in the desired place. For non-Firefox data, there simply is no mechanism at all. Even the file `torrc`, which exists in the source code, never actually gets installed on macOS (which I suppose is tolerated because it's an empty file, so who cares if it gets installed?). |
|
|
||
| ## What is this external user data craziness? | ||
|
|
||
| It turns out that Tor Browser for macOS does something very different from Tor Browser for GNU/Linux and Windows. On macOS, the user data directory is stored separately from the application executable code. To make matters worse, on macOS there is no way to supply "default" contents for the user data directory. In fact, in order to set the default bookmarks for Firefox, Tor Browser on macOS does some kind of witchcraft involving stuffing the bookmarks file inside one of the Firefox application archives, such that when Firefox eventually creates a fresh profile, the bookmarks end up in the desired place. For non-Firefox data, there simply is no mechanism at all. Even the file `torrc`, which exists in the source code, never actually gets installed on macOS (which I suppose is tolerated because it's an empty file, so who cares if it gets installed?). |
There was a problem hiding this comment.
(which I suppose is tolerated because it's an empty file, so who cares if it gets installed?).
I suppose this is tolerated because it's an empty file; who cares if it gets installed?
|
|
||
| I considered a few options here. Initially the thought occurred to me of patching Electrum-NMC to support a read-only config file in a separate directory from its writeable data directory. Alas, this seemed rather invasive, and I didn't want to write a complex patch without good reason. I also considered generating the config file on-demand as part of Tor Launcher, but this was also not going to be very clean. Instead, I realized that we could just pass the config options we cared about as command-line flags, not supply a default config file at all, and be done with it. | ||
|
|
||
| Oh wait. Murphy says no. Turns out that the RPC port settings in Electrum can't be set on the command-line, only in the config file. Upon consulting with SomberNight from upstream Electrum, he pointed me to a spot in the relevant Python source, where I could probably do a 3-line patch that would do what I want, and would probably be upstreamable without controversy. This ended up working very well. We were thus able to launch Electrum-NMC. |
There was a problem hiding this comment.
As above, I dislike titles.
|
|
||
| A minor tweak was needed for StemNS, so that it would search for `ncprop279` relative to StemNS's script directory instead of relative to the `PATH`. Turns out that macOS doesn't standardize the `PATH` in the way that GNU/Linux and Windows do, so relying on the `PATH` wasn't usable on macOS. Not too bad. | ||
|
|
||
| I also took the opportunity to do some minor refactoring/cleanup of StemNS, mostly related to error handling and debug logging. Now the console output of StemNS is actually likely to be informative. (My beta testers very much appreciated this.) |
There was a problem hiding this comment.
refactoring/cleanup
refactoring and cleanup
|
|
||
| ## StemNS Support | ||
|
|
||
| A minor tweak was needed for StemNS, so that it would search for `ncprop279` relative to StemNS's script directory instead of relative to the `PATH`. Turns out that macOS doesn't standardize the `PATH` in the way that GNU/Linux and Windows do, so relying on the `PATH` wasn't usable on macOS. Not too bad. |
There was a problem hiding this comment.
Why is it not too bad that you can't rely on the PATH on macOS?
Upon re-reading, I realize the "not too bad" applies to how much work it was, but this should probably be re-worded so it's obvious the second sentence is related to the first
|
@yanmaani I've fixed some of the wording, can you take a look again? |
|
De gustibus. I still think you should reword "started up a build job. In order to build without errors" though - I genuinely find that hard to read. |
As usual, if no showstoppers are raised within 3 days, I'll fix the time value and then merge. (Do not merge directly since it will have the wrong time value.)