Build is broken

[cmars]

The build here has been broken for a while and your Tor version is pretty old. Any interest in reviving this?

I managed to get it working again with current patched Tor at https://github.com/cmars/go-libtor/actions/runs/1901538112. In the process I did some extensive refactoring of the build process to use Mage, modularizing the build in the process. Doesn't support the lockfile thing, but that'd be easy enough to add.

No idea if iOS support still works but it could probably be revived. I don't have an iPhone, nor interest in supporting them at this time. I'd rather work on adding Windows msys support.

Should I propose a PR here at some point?

[n0izn0iz]

Yes! But I think there is a go-libtor repo owned by another org with better maintenance

[EDIT] Can't seem to find it, so I guess just yes

[cmars]

Was it https://github.com/ipsn/go-libtor? I started with that one but found yours was a bit better :D

GitHub

GitHub - ipsn/go-libtor: Self-contained Tor from Go

Self-contained Tor from Go. Contribute to ipsn/go-libtor development by creating an account on GitHub.

[n0izn0iz]

I'm not sure but I only found this one too

@Jorropo what do you think about this?

He was the last person working on this repo and seems to have a running update bot

[Jorropo]

@n0izn0iz @cmars I belive the reason the CI is broken is because github's macos runner runs with a too new version of autoconf that tor doesn't support. I don't think there is any problematic breaking changes and just removing the version check of autoconf in tor would be enough. (or making it accept this more updated version)

However this codebase is running with tor 3.x which is deprecated and doesn't isn't supported anymore (for relays at least).
Just fixing this wouldn't do much, someone would need to update to tor 4.x which require more work to fit to the new APIs.

EDIT:

configure.ac:295: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:295: You should run autoupdate.
./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...

That the autoDarwin failing (while autoLinux runs perfectly fine).
The build fails like this. Which isn't just the version check, it does seem tor use an outdated macro.
I guess downgrading autoconf in the darwin runner would be a better option. That would be easy to do, but doesn't fix the 3.x vs 4.x issue.

[Jorropo]

Should I propose a PR here at some point?

@cmars

You can try if you want, however I have checked your branch and I have a few issues with it. (Like linux testing being moved before autoDarwin, testIOS removed, ...). :)

I think if you open PR you should include the minimal commits that get it building (mainly autoconf downgrade).

[hellais]

FWIW we got go-libtor working with the latest 0.4.x series of tor in our fork of it: https://github.com/ooni/go-libtor.

Our target platforms are only mobile (iOS and Android), so not much testing has been done for desktop. That said it would be great if we could consolidate efforts in a single fork so we aren't all duplicating a bunch of work.

I proposed this in the following issues: #6 ipsn/go-libtor#33, but haven't really heard back from any of the maintainers.

GitHub

GitHub - ooni/go-libtor: Self-contained Tor from Go

Self-contained Tor from Go. Contribute to ooni/go-libtor development by creating an account on GitHub.

[Jorropo]

@hellais nice work you did there 🙂

I used to work on this but I don't anymore (I switched jobs).

cc @berty/network-labs (this would be the team that claim over this) afaik this is not being prioritized for them.

[aeddi]

For the moment we don't work on it anymore and we don't plan to do it again anytime soon.

In the case of Berty, in addition to go-libtor, it would remain to make the native part specific to iOS and Android which can be complicated due to the structure of the C code and the limitations of the mobile OS APIs, in particular the iOS one.

We would then need to make our different layers communicate through this transport, which again won't be an easy task, we have already done tests to run Berty through a ToR proxy and we found several problems more or less complicated to solve.

It would imply a lot of development effort to get something working on our side and with the number of tasks to be done that are of higher priority, it is likely that the integration of Tor in Berty will be frozen for a long time.

Very glad to see that people are still working on it though, we will definitely use and contribute to your work when the time comes for us to get back to it. 👍

[Techno-Fox]

I'd also love to see windows support being added, though how would it work with cross compiling?

[hkparker]

@hellais I've noticed an issue building for desktop on your fork, can you enable issues on the repo so that I can start a discussion there? Linux builds are looking for a mach header file.