3 ms·

Although it wasn't the cause of this particular vulnerability, this kind of application, which communicates with large numbers of potentially malicious nodes, s

by ptx 2y ago

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.

xelamonster 2y ago
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?
- result2vino 2y ago
  libtorrent’s configuration documentation gives a glimpse into the massive hidden complexity of writing a good, performant, resilient client.
65a 2y ago
There are several pure Go bittorrent libraries from a cursory search
- ptx 2y ago
  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_clients#Interface_and_programming https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clien... [1] https://github.com/BiglySoftware/BiglyBT https://github.com/BiglySoftware/BiglyBT
  - iso8859-1 2y ago
    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.
- Groxx 2y ago
  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.
  - 65a 2y ago
    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"
    - deleted 2y ago
      [deleted]
Svenskunganka 2y ago
There is rqbit written in Rust and does not rely on libtorrent: https://github.com/ikatson/rqbit https://github.com/ikatson/rqbit

by ptx 2y ago

xelamonster 2y ago

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?

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

65a 2y ago

There are several pure Go bittorrent libraries from a cursory search

ptx 2y ago
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_clients#Interface_and_programming https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clien... [1] https://github.com/BiglySoftware/BiglyBT https://github.com/BiglySoftware/BiglyBT
- iso8859-1 2y ago
  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.
Groxx 2y ago
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.
- 65a 2y ago
  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"
  - deleted 2y ago
    [deleted]

Svenskunganka 2y ago

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