Mutable bittorrents...

[ChefBourgeoisie]

As most of you all know, once a torrent has been created and seeded by whoever starts it, the files it hands out are chiseled in stone. No one can update a screwed up file, add a missing file, remove a file included mistakenly, etc.

Except awhile back, a standards document was released. BEP #46 - "Updating Torrents Via DHT Mutable Items"

Long story short: If torrent software implemented this functionality, the person who started the torrent could come back and update it later. He could, for instance, start a torrent with the first episode of a tv series... and every week on Wednesday night, add the new episode. As soon as he did, anyone still running that particular torrent would start downloading the new episode (except dirty leeches who delete it after getting the first episode, lol!). This is done in a way that is as secure as the original bittorrent protocol... it doesn't make anything worse.

But no one has ever bothered. Too difficult, or too boring, perhaps unnecessary to the purists. I'm not sure why. I got tired of waiting.

I think I have a working implementation. In Transmission. I had to brag somewhere.

 

[CasketBase]

But no one has ever bothered. Too difficult, or too boring, perhaps unnecessary to the purists. I'm not sure why. I got tired of waiting.

maybe because it allows malicious actors to fuck with people by starting a clean torrent and then adding a whole zoo of rats, worms and trojans to it later on if it gets spread around?
not saying you shouldn't do what you did or what you did wasn't useful tho

 

[ChefBourgeoisie]

maybe because it allows malicious actors to fuck with people by starting a clean torrent and then adding a whole zoo of rats, worms and trojans to it later on if it gets spread around?

I think rugpulls would be the worst form of griefing. They give it to you. Give it to everyone, then wait until a time judged to be when most people would be away, and delete the files in a torrent update.

I've added an interface that lets you choose (default, or per torrent) whether you want it to update, with the following choices:

1. Never
2. When offered
   A. (checkbox) Rename files
   B. (checkbox) Overwrite files
   C. (checkbox) Delete files
   D. (checkbox) Additional files
3. Always versioned
   A. (integer limit) Maximum storage
   B. (count limit) Last n versions

And even if you do allow updates, it still notifies you and you have to click "Accept" or it to get the update.

You get to control if you want to accept updates. If they can include viruses or malware in a download, why would they wait weeks to do it? I don't expect that it's particularly more abusable than pre-BEP46 bittorrent.

 

[Billow Riley]

I could see this being useful for something like Anna's Archive. They could directly update their torrents instead of publishing new batches that seeders need to grab with a script.

 

[StacticShock]

I could see this being useful for something like Anna's Archive. They could directly update their torrents instead of publishing new batches that seeders need to grab with a script.

pretty much that, otherwise people will just use to fuck others over, or allowing a versioning situation where the first version of the torrent could be downloaded and kept somewhere and people can just choose which version of the torrent to keep, showing which files are changed and whatnot, that's be great for lots of things but in my use case, games.

 

[XYZpdq Jr.]

yeah I can see ten ways this is useful for Weekly TV Show and ten thousand ways this is useful for lol fuck you

 

[ChefBourgeoisie]

If anyone is capable of building this from source:

https://github.com/NoMoreNicksLeft/transmission

Work in progress. macOS and cli have support. Gtk sometime this weekend. Qt (Windows) will be last. Once things are moderately sane, I'll push up some release candidate packages soon after, regular installers at that point, but it could still be a week out. If anyone wants to help test, I'll put up some trash torrents with text files and you can see as I add or delete those, learn how it works.

 

[Squishie PP]

If anyone is capable of building this from source:

https://github.com/NoMoreNicksLeft/transmission

Work in progress. macOS and cli have support. Gtk sometime this weekend. Qt (Windows) will be last. Once things are moderately sane, I'll push up some release candidate packages soon after, regular installers at that point, but it could still be a week out. If anyone wants to help test, I'll put up some trash torrents with text files and you can see as I add or delete those, learn how it works.

Just built it on Linux Mint:

[ 98%] Building CXX object tests/libtransmission/CMakeFiles/libtransmission-test.dir/variant-test.cc.o
[ 98%] Building CXX object tests/libtransmission/CMakeFiles/libtransmission-test.dir/watchdir-test.cc.o
[100%] Building CXX object tests/libtransmission/CMakeFiles/libtransmission-test.dir/web-utils-test.cc.o
[100%] Linking CXX executable libtransmission-test
[100%] Built target libtransmission-test

 

[ChefBourgeoisie]

I will be posting beta releases on the Github repo for Mac and Windows users shortly. Linux too, once I know which package managers I'm going to target.

Also going to try to come up with some toy torrent that shows off the updating torrents, but still not sure what that should look like. But if two of you were to test the releases, you can do that yourselves in the meantime.

 

[Squishie PP]

Linux too, once I know which package managers I'm going to target.

When in doubt, just create an appimage.

 

[ChefBourgeoisie]

Windows beta release is posted, but I have no machine to test it on. Might just crash.

 

[dick brain]

If they can include viruses or malware in a download, why would they wait weeks to do it?

Why wouldn't they?

Upload a compromised torrent, risk getting caught on uploading to a tracker, then infect downloaders one by one until someone notices and reports
Or
Upload a clean torrent, no risk of getting screened out, amass a bunch of what are effectively backdoors to downloaders' devices, then push malware to all of them at once, infecting all of them simultaneously before any of them can possibly report.

They have every incentive.

 

[ChefBourgeoisie]

This can't "push malware" to them. If they've chosen to download the file, and if they've chosen to subscribe to updates, then the best you can do with this is push a new file to them. Which they might never run anyway, even if subscribed. The original that they got on the first try still works, why would they install another version?

And why are you torrenting executables so casually?

The trouble with malware security is that everyone is overly paranoid when the risks are low, and absolutely gullible when the risks are high. But you don't have to use it, I just implemented it. I have use cases where there is essentially no additional risk above that of non-mutable torrents.

 

[Civillian 18]

Unless there is a bug within your implementation/setup (do x on download complete etc) then the torrent client will never execute files it downloads no?
There is inherently more risk that someone could compromise a 'trusted' account and push malware but it would still need to be executed.

Is there any consideration for impersonating a torrent creator and pushing from their own client?

 

[ChefBourgeoisie]

There is inherently more risk that someone could compromise a 'trusted' account and push malware but it would still need to be executed.

If people treat the PEM key for the torrent like the password it is, if they store it in a password manager, then compromising a torrent would require some magical cryptography superpowers. Maybe the NSA will be able to do it in 20 years, but that's the level of effort.

Unless there is a bug within your implementation/setup (do x on download complete etc) then the torrent client will never execute files it downloads no?

Never. Merely writes the files to a place the leecher specifies. And if he is satisfied with the original, there might be little reason to bother with an updated version... I won't say that there's absolutely zero concern here. An attacker who is inhumanly patient might play the long con, providing one good file after another over a period of weeks, to lull people into running the bad version that they send out later. But that's a rare personality type. And easily defeated by just never accepting updates.

The use case for this is for the type of piracy where there are associated files coming in the future that aren't released yet. Episodes in a tv show that's ongoing. Magazine subscriptions maybe. From some trusted groups I might accept updates of one-off files. I get annoyed having to go back a day later and see if anyone's put out the repack yet. But I'd only do that on a case by case basis (and it not being executable, the worst they can do is update it with an even worse encode).

If people try this and say "hey, the defaults are a little wonky, and some dumb people might misconfigure it to cause themselves trouble", I will pay attention and see if I can make those better. But those defaults are pretty tight even now. I think not only will people like this, it will be rather practical, easy to use, and won't lead to any grief that isn't already taking place anyway.

 

[Civillian 18]

If people treat the PEM key for the torrent like the password it is, if they store it in a password manager, then compromising a torrent would require some magical cryptography superpowers. Maybe the NSA will be able to do it in 20 years, but that's the level of effort.

That is what I thought, there would be the initial signing/key that would make impersonation 'impossible' and collision unlikely.

From trusted groups

This is the key really, there are a bunch of scene groups that can at least be trusted to be consistent in their quality, if not their credibility in the scene. It would work really well for finite or known-length (TV show seasons, video game files w/ updates) purposes. It is super interesting.

 

[autosarcophagy]

i always wanted a p2p torrent site maybe even on tor with something like onionshare a program that uses tor. the p2p part would be sharing the database of torrents with other users or choose what torrent you want to share.maybe you can even add sources with jackett.because the biggest problem with BitTorrent is easily finding the hash of a file you want to download and that part should also be harder to take down and i don't think cloud flare is a long term solution for this problem.

 

[ChefBourgeoisie]

i always wanted a p2p torrent site maybe even on tor with something like onionshare a program that uses tor.

I too want this. In addition to forking Transmission and adding BEP46, I've done the same with Webtorrent, a javascript library that adds torrent support to web pages... in the browser. There are some limitations (it can't open arbitrary udp/tcp ports, and uses WebRTC connections as a substitute) meaning it can't connect to the same DHT that Transmission does. But I wouldn't be using this for regular "I want to download files" mutable torrents anyway.

I've got a scheme in mind where a website-like-thing wouldn't have a server at all. You'd download the latest version of it through torrenting, and it would update in (near) real-time the same way. I'm calling this "swarm-hosting". For the longest time I couldn't figure out how users would post back to it (essential if we wanted a tracker, and not just some shitty blog)... but I've recently had an epiphany. The posts don't have to go back to the publisher of the swarm-hosted site... they could just be passed around the swarm itself, and everyone's copy of the site/webapp appends those post where they belong. No moderation possible, no jannies. This could be a true shitfest (maybe in the best possible sense?). Going to prototype this, and anyone will be able to check it out without installing software. You'll just load a html file into a browser tab, and there it will be.

Others could run similar "websites". They'd have no domain names. No IP addresses. The authorities couldn't seize them. Couldn't block them. With simple precautions, the person publishing the website could be moderately-strongly anonymous.

 

[SCV]

Do you have any plans to get this upstreamed for transmission? Usually the problem with these sorts of things is a chicken and egg dilemma between the clients and trackers but it seems like you've made the egg here.

 

[ChefBourgeoisie]

Do you have any plans to get this upstreamed for transmission?

I'm not hopeful that they'll accept it. But it builds and works now, you could just use what I've got. If there's a particular platform you want a release for, I can build it for you.