Hacker News Reader

Comment by ptx | Hacker News Reader

Although it wasn't the cause of this particular vulnerability, this kind of application, which communicates with large numbers of potentially malicious nodes, seems like it would really benefit from memory safety, but all the current implementations seem to be written in C++. (The article does mention the potential for this kind of vulnerability in point 4.)

Even Deluge, which is written in Python, relies on libtorrent which is written in C++.

I don't suppose there is a modern fork of the old Java-based Azureus client? Many BitTorrent clients nowadays split the GUI from the daemon process handling the actual torrenting, so using Java for the daemon and connecting it to a native GUI could strike a good balance between security, performance and user experience.

View on HN

There are several pure Go bittorrent libraries from a cursory search

Are there any GUI clients based on those libraries? Wikipedia's list[0] doesn't include any.

But it does include, I see now, exactly what I was asking for – apparently there's an actively developed fork of Azureus called BiglyBT[1].

[0] https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clien...

[1] https://github.com/BiglySoftware/BiglyBT

It's heartwarming to see that the spirit behind Azureus is still alive. SWT might not be what the Duke himself wants in a Java GUI framework, but it's practical and I remember the "chunks bar" in the Azureus GUI fondly. It'll enjoy firing up BiglyBT after all these years. Using a largely memory safe language makes a lot of sense for P2P software.

Potentially worth pointing out that Go is memory safe only when single threaded (races can corrupt memory), and this kind of application is very likely to use multiple threads.

But I do also generally expect it to be safer than C++. The race detector prevents a lot of badness quite effectively because it's so widely used.

Go is safe from the perspective of RCEs due to buffer overflow, which is what matters here. Happy to be enlightened otherwise, but "I broke your (poorly implemented, non-idiomatic, please use locks or channels ffs) state machine" is a lot better than "I am the return instruction pointer now"

There is rqbit written in Rust and does not rely on libtorrent: https://github.com/ikatson/rqbit

I'm going to ask a lazy question instead of figuring it out myself for the sake of discussion, feel free to ignore if I should just Google it:

Where would one start in building an alternative to libtorrent? Have there been any attempts (or successes)? Any functional clients that use other implementations?

libtorrent’s configuration documentation gives a glimpse into the massive hidden complexity of writing a good, performant, resilient client.

Reply on news.ycombinator.com