Bombadillo fails with .onion #118

New Issue

sloum · 2019-12-07T16:11:57Z

sloum commented

2019-12-07 16:11:57 +00:00

I do not use tor. Never have. Have meant to. However, user uwu reports in the circumlunar.space irc that:

01:25:12 [uwu] sloum: haven't really had time to play with it, but at first glance it looks like bombadillo chokes on .onion links
01:29:00 [uwu] with a working torsocks setup, ofc

I do not know what the second message means, but I assume they are precursors to running tor.

If at all possible I would like Bombadillo to be able to work over tor/with .onion links. @asdf do you know anything about this? Having a place to start would be helpful.

I do not use tor. Never have. Have meant to. However, user `uwu` reports in the circumlunar.space irc that: ``` 01:25:12 [uwu] sloum: haven't really had time to play with it, but at first glance it looks like bombadillo chokes on .onion links 01:29:00 [uwu] with a working torsocks setup, ofc ``` I do not know what the second message means, but I assume they are precursors to running tor. If at all possible I would like Bombadillo to be able to work over tor/with .onion links. @asdf do you know anything about this? Having a place to start would be helpful.

sloum added the

enhancement

label 2019-12-07 16:11:57 +00:00

sloum commented

2019-12-07 21:59:22 +00:00

There is some evidence that this works in VF-1 so maybe use VF-1 as a reference to try to debug the issue. I'm not sure at all why this doesnt work :-/

I dont know how onion stuff works. I'm going to mark this help wanted.

There is some evidence that this works in VF-1 so maybe use VF-1 as a reference to try to debug the issue. I'm not sure at all why this doesnt work :-/ I dont know how onion stuff works. I'm going to mark this help wanted.

sloum added the

help wanted

label 2019-12-07 22:00:11 +00:00

sloum commented

2020-02-02 16:02:44 +00:00

User waldfee reached out to me via e-mail to point me toward this information:

https://golang.org/pkg/net/#hdr-Name_Resolution

It seems that on nix system there are two resolver options. The pure Go one donks up tor hidden service routing. However, a flag can be passed to use cgo for resolving addresses. In theory passing a flag at build time should solve the issue.

So, do we:

Update the makefile to use the environment variable that will switch it over to cgo
Update the documentation so that users can add it manually during build
Do a combination of both where we update it to cgo but provide documentation to switch it back to pure go if desired

It turns out that this issue should only affect nix systems and that OSX does not allow programs to make direct DNS requests and have to go through the system, so C go is automatically used there.

The difference between pure go and cgo, from a performance perspective, is a coroutine vs a system thread.

@asdf what do you think?

User `waldfee` reached out to me via e-mail to point me toward this information: https://golang.org/pkg/net/#hdr-Name_Resolution It seems that on nix system there are two resolver options. The pure Go one donks up tor hidden service routing. However, a flag can be passed to use cgo for resolving addresses. In theory passing a flag at build time should solve the issue. So, do we: 1. Update the makefile to use the environment variable that will switch it over to cgo 1. Update the documentation so that users can add it manually during build 1. Do a combination of both where we update it to cgo but provide documentation to switch it back to pure go if desired It turns out that this issue should only affect nix systems and that OSX does not allow programs to make direct DNS requests and have to go through the system, so C go is automatically used there. The difference between pure go and cgo, from a performance perspective, is a coroutine vs a system thread. @asdf what do you think?

asdf commented

2020-02-04 06:08:06 +00:00

Thanks waldfee for providing advice on this. Much appreciated!

I'm not 100% sure from your message if this has been validated as a fix for this issue. This might be as simple as running the build command:

GODEBUG=netdns=cgo make

Or perhaps it means doing:

export GODEBUG=netdns=cgo 
make

Also, I don't understand the impact of the issue. Is this only for users of tor, or for anyone attempting to visit a site on that domain?

I'd be leaning toward having this as a compilation option, not knowing what impacts changing the default options might have.

Thanks waldfee for providing advice on this. Much appreciated! I'm not 100% sure from your message if this has been validated as a fix for this issue. This might be as simple as running the build command: ```shell GODEBUG=netdns=cgo make ``` Or perhaps it means doing: ```shell export GODEBUG=netdns=cgo make ``` Also, I don't understand the impact of the issue. Is this only for users of tor, or for anyone attempting to visit a site on that domain? I'd be leaning toward having this as a compilation option, not knowing what impacts changing the default options might have.

sloum commented

2020-02-04 22:26:50 +00:00

My understanding (I have never used Tor) is that only users actively wanting to use Tor need this mode. I believe your first example should work just fine and could be used with sudo make install as well.

As it has been explained to me any performance hit for defaulting to that setting should be minimal. That said, I do like the idea of a pure go implementation rather than using cgo.

The TODO for this will depend on course of action, but it seems like we are leaning toward the documentation route. I will make a branch and add this info to the install documentation. That will let people have the option of deciding to do this or not. I'll make it pretty simple and let people know that if they want to use Bombadillo over Tor this will be necessary.

My understanding (I have never used Tor) is that only users actively wanting to use Tor need this mode. I believe your first example should work just fine and could be used with `sudo make install` as well. As it has been explained to me any performance hit for defaulting to that setting should be minimal. That said, I do like the idea of a pure go implementation rather than using cgo. The TODO for this will depend on course of action, but it seems like we are leaning toward the documentation route. I will make a branch and add this info to the install documentation. That will let people have the option of deciding to do this or not. I'll make it pretty simple and let people know that if they want to use Bombadillo over Tor this will be necessary.

asdf was assigned by sloum

2020-02-04 22:26:55 +00:00

asdf was unassigned by sloum

2020-02-04 22:26:56 +00:00

sloum self-assigned this 2020-02-04 22:26:57 +00:00

asdf commented

2020-02-05 00:57:44 +00:00

Agreed, I think documenting it is the right balance here.

Once it is ready, it would be great to get further feedback from uwu, walfee or anyone else as to how well it works, what the experience is like, and if there are other issues.

cool

Agreed, I think documenting it is the right balance here. Once it is ready, it would be great to get further feedback from uwu, walfee or anyone else as to how well it works, what the experience is like, and if there are other issues. cool

sloum commented

2020-03-04 17:37:05 +00:00

I am now hearing from some folks that the solution discussed above only works under certain conditions. It may still be worth adding to the docs, but I am hesitant to dive into official tor support given my lack of knowledge on the subject.