haveno-dex
update tor to 0.4.8.9
This PR updates the Tor browser version to 13.0.6 and the tor binary version to 0.4.8.9. It does so by using a self-updated fork of netlayer. The fork of netlayer uses this PR directly, as the most current version of the tor binary on bisq-network/tor-binary is 0.4.7.10.
Ideally, using forks and commits in this way would not happen. However, the tor-binary PR hasn't been merged or meaningfully addressed after 3 months, and netlayer seems to be continually abandoned and forked. Unsure how to proceed, if not in this way.
(Addresses #789 )
Cool, we can fork netlayer if that lets us move forward.
I'm getting this error in the app with this PR applied:
And this stacktrace:
Feb-25 11:00:49.463 [JavaFX Application Thread] INFO haveno.core.app.WalletAppSetup: Initialize WalletAppSetup with monero-java version 0.8.10
Feb-25 11:00:49.466 [PriceRequest @ http://elaxlgigphpicy5q7pi5wkz2ko2vgjbq4576vic7febmx4xcxvk6deqd.onion/] ERROR h.n.p2p.network.TorNetworkNode: Error at getSocksProxy java.lang.IllegalArgumentException: Parameter specified as non-null is null: method org.berndpruenster.netlayer.tor.Tor.getProxy, parameter proxyHost
at org.berndpruenster.netlayer.tor.Tor.getProxy(Tor.kt)
at org.berndpruenster.netlayer.tor.Tor.getProxy$default(Tor.kt:240)
at org.berndpruenster.netlayer.tor.Tor.getProxy(Tor.kt)
at haveno.network.p2p.network.TorNetworkNode.getSocksProxy(TorNetworkNode.java:114)
at haveno.network.Socks5ProxyProvider.getSocks5ProxyInternal(Socks5ProxyProvider.java:85)
at haveno.network.Socks5ProxyProvider.getSocks5Proxy(Socks5ProxyProvider.java:68)
at haveno.network.http.HttpClientImpl.getSocks5Proxy(HttpClientImpl.java:332)
at haveno.network.http.HttpClientImpl.doRequest(HttpClientImpl.java:145)
at haveno.network.http.HttpClientImpl.get(HttpClientImpl.java:127)
at haveno.core.provider.price.PriceProvider.getAll(PriceProvider.java:55)
at haveno.core.provider.price.PriceRequest.lambda$requestAllPrices$0(PriceRequest.java:50)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
I’ll look into that; I should also note that I have already had to change the netlayer fork a bit to fix some odd errors (for example, the directory path to the tor binary for macOS was set to “tor.real” instead of….. just “tor”. My guess is this is something similar but for the proxy setting
This fixes the error, however I am unsure if it is actually correct behavior.
The issue with the code before was that the if statement that I changed ran with a null socksProxy but streamIsolation was set to false, the code within the if statement would execute, despite the stream variable never being initialized by the if statement above it.
What it now does is create and announce an onion address, wait around a bit, complain with "Exhausted price provider list, looping to beginning", create another onion address, and repeat until the app is closed. Probably not correct behavior. I am currently unsure exactly why socksProxy is null/why streamIsolation is false, I'll need to look into that further.
Thanks for this. Please rebase on the latest master. We'll need to change the preland repo to haveno, but we can do that after tested.
Failing with a dependency verification. Run ./gradlew --write-verification-metadata sha256 to fix.
Great news. @napoly updated us to the latest TOR from Bisq in #810, which fixes the error we saw in this PR:
Error at getSocksProxy java.lang.IllegalArgumentException: Parameter specified as non-null is null: method org.berndpruenster.netlayer.tor.Tor.getProxy, parameter proxyHost.
Please rebase once more, removing the fix you made in TorNetworkNode.java, and I will test in Ubuntu ARM64. Thanks!
This is working for me on mac. :)
I guess next step would be to transition from the preland repo to haveno then.
That sounds good! When such a repo exists, I can port it to that one instead
The netlayer repo is ready for your update: https://github.com/haveno-dex/netlayer
FYI this does not change the behavior on master, which works on macOS as a native ARM64 app, but fails on Ubuntu ARM64 VM on macOS with this error, suggesting x86 version is still being used somewhere?
Mar-12 13:04:36.567 [StartTor] INFO o.b.netlayer.tor.Tor: Starting Tor
Mar-12 13:04:36.585 [ERR] ERROR o.b.netlayer.tor.Tor: rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2
Mar-12 13:04:36.685 [ERR] ERROR o.b.netlayer.tor.Tor:
Mar-12 13:04:36.686 [StartTor] ERROR h.n.p2p.network.TorNetworkNode: Starting tor node failed org.berndpruenster.netlayer.tor.TorCtlException: Could not setup Tor
at org.berndpruenster.netlayer.tor.NativeTor.<init>(NativeTor.kt:106)
at org.berndpruenster.netlayer.tor.NativeTor.<init>(NativeTor.kt:55)
at org.berndpruenster.netlayer.tor.NativeTor.<init>(NativeTor.kt)
at haveno.network.p2p.network.NewTor.getTor(NewTor.java:107)
at haveno.network.p2p.network.TorNetworkNode.lambda$createTorAndHiddenService$10(TorNetworkNode.java:172)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.io.IOException: java.io.IOException: Tor exited with value 133
at org.berndpruenster.netlayer.tor.TorContext.installAndStartTorOp(TorContext.kt:392)
at org.berndpruenster.netlayer.tor.NativeTor.<init>(NativeTor.kt:66)
... 8 common frames omitted
Caused by: java.io.IOException: Tor exited with value 133
at org.berndpruenster.netlayer.tor.TorContext.installAndStartTorOp(TorContext.kt:354)
... 9 common frames omitted
Hey, we're pushing towards a next release. Hoping the netlayer repo can be updated and this can make it in? :)
Switching over to the netlayer repo can occur as soon as the repo is ready.
The aforementioned error mentions Rosetta, which is MacOS's general-purpose translation error (doesn't exist on non-MacOS as far as I know); in addition, it seems to be having issues with accessing the linux linker for some reason, which is also quite odd.
This may be related to this issue mentioned on Docker; I think we can safely ignore this unless someone on native ARM64 or a non-MacOS VM has the issue as well.
think we can safely ignore this unless someone on native ARM64 or a non-MacOS VM has the issue as well.
Agreed. It's not introducing any new issue.
Currently working on it; I just opened up a PR on the tor-binary repo because the original links no longer work
(That commit will fail for now, as I can't verify tor-binary because it can't find it until the link is updated)
Thanks, I've merged your PR to tor-binary.
By the way, I think the last obstacle to supporting arm64 is to use the tor binary for arm64. Currently it's downloading and trying to use x86_64 binary.
However, it's not necessary for this PR, which merely upgrades tor support across what is already supported.
Something to note for arm64 tor support is that they only officially support arm64 for Mac and for android; so for linux arm64 we would have to use the android version (Another thing to note is that the current version of tor we have updated to does not have android arm64, only macos arm64)
Something to note for arm64 tor support is that they only officially support arm64 for Mac and for android; so for linux arm64 we would have to use the android version (Another thing to note is that the current version of tor we have updated to does not have android arm64, only macos arm64)
Ok, best to forget that now then, and proceed with the update across what we already support.
Thanks, ideally you should squash your commits to 1 as well, but I can do that and enter a commit message as well.