[Request] Add "hash" as parameter to /api/torrents/filter

[TGKx]

Some other trackers support searching torrents by hash. This can be used to enable things like pulling descriptions or other information (such as confirming an upload completed) for automating uploads via upload-assistant.

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[Roardom]

It should be mentioned that providing users with the info_hash allows them to connect to existing peers if they can guess an IP and download the torrent, without ever announcing to the tracker or downloading the .torrent file. Ideally the info_hash shouldn't be provided/searchable to non-staff apart from the .torrent download and should be randomized on upload.

[TGKx]

I appreciate the consideration for the security implications of any API change. Relating to this particular request I'd like to highlight that:

1. The info_hash response is already included in the filter API.
2. The filter API requires authentication which excludes anonymous users from obtaining one half of the information required to blindly join a swarm and bypassing the tracker.
3. This request is to allow a submitter to query the API by a known info_hash, and the response would be the same info_hash they submitted, so there is no new information revealed.
4. The API has throttle protections against trying to brute force or stuff info_hashes blindly. I'm not sure what the point would be of doing this by an authenticated user who can already search/download torrents through the site, but keen to hear if there is a unique threat vector. If an adversary were wanting to farm hashes, they could simply run an unfiltered search and pickup the top 100 hashes that way. If that were disabled, the adversary could simply download the .torrents returned from a search and obtain the same info.
5. The info_hash can't be randomized as it is deterministic based on the hashable fields (name, paths, etc) of the .torrent file.
6. An info_hash is not typically considered a 'secret' by most trackers, vs. the api keys or announce url ID. To mitigate the threat you are talking about, it is more typical to protect the IP address(es) of users and there are also privacy benefits to doing this.

Based on the above, I can't see any net-new risk with the feature request, but I am keen to further evaluate if you have something in mind.