mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
qBt not checking if files exist when using Seed mode(Skip hash check) #9616
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#9616
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Jan 8, 2020).
qBittorrent version and Operating System
4.2.1, Win10
What is the problem
Qbt does not check if destination file exists when using seed mode. It directly goes into seeding mode even if you select an empty directory. One could select a wrong directory when adding a file for re-seeding or cross-seeding but qBt won’t complain that the files are missing. It continues to be in seeding state unless someone tries to leech the torrent from that user.
This also has some potential cheating implications. One could get seed hours/seedbonus in private trackers without having the actual files in their disk.
What is the expected behavior
Check if the file exists before going into seeding mode.
Steps to reproduce
Just add some torrent in qBt with skip hash check box ticked. (make sure that torrent has no leecher. Otherwise it will reset back to 0%).
@FranciscoPombal commented on GitHub (Jan 13, 2020):
Well, this part seems correct:
The problem is going directly into seeding state in the first place.
@glassez commented on GitHub (Jan 13, 2020):
Well, can someone to summarize the problem?
@ghost commented on GitHub (Jan 13, 2020):
Case# 1. I’ve already downloaded a torrent from one tracker and want to seed that in another. I don’t want qBit to recheck the hash when adding the torrent from other tracker. Remember, info hashes can be different across trackers so trackers won’t merge in all use cases. A new torrent will get added and recheck will commence unless skip hash chk is used.
Case#2. I’ve removed a torrent from qBit, want to re-seed it. Don’t want qbit to recheck.
Case #3. I’m uploading a torrent to a private tracker. After uploading I’ve to redownload the metafile to add passkey. I won’t like to waste time in qBit rechecking the file again.
Tick skip hash check when adding torrent.
When that option is checked during adding torrent, check if the files already exist in the directory or not. If not present, don’t apply skip hash check, instead add that torrent as usual Without skipping hash checking.
@glassez commented on GitHub (Jan 13, 2020):
IIRC, we are talking about checking of files. Info hash has nothing to do here.
Do you mean the case when the user did this accidentally?
What's about the case when user doesn't really want to download anything? E.g. it has the torrent content previously downloaded (but files were renamed that time).
@FranciscoPombal commented on GitHub (Jan 13, 2020):
@an0n666 even with the changes you are suggesting, a cheater could just create the correct folder structure + 0-size files with the correct names, and qBittorrent would go directly into seeding mode when "skip hash check" is on.
Perhaps it is better to get rid of the option altogether? It would be kind of inconvenient, especially for case 3.
But the metafile redownload in step 3 can generally be avoided as far as I know by setting the correct passkey and source flag (
-sflag inmktorrent) from the start.As for the other 2 cases, you'd just have to live with the recheck, which means a little extra "downtime".
@glassez commented on GitHub (Jan 13, 2020):
Maybe it's better to go into "Missing files" state if option is enabled but there are no files exist?
@FranciscoPombal commented on GitHub (Jan 13, 2020):
@glassez
Would not stop the potential cheating issue raised in the
OPthe first comment, see my comment above.@glassez commented on GitHub (Jan 13, 2020):
Sorry, I answered another comment.
BTW, I don't intend to fight with cheeters. F there is valid use case of this option I would fix it, otherwise let's remove it totally.
@FranciscoPombal commented on GitHub (Jan 13, 2020):
If you ignore the cheating issue, all 3 cases mentioned above are legitimate uses of the feature. However, there should be a simple check for missing files and, like you mentioned:
Yep.
@glassez commented on GitHub (Jan 13, 2020):
Well, then I want to hear more opinions about "cheating issue". Should we drop "Skip hash check" option or not?
@sledgehammer999, @Chocobo1, @thalieht?
@ghost commented on GitHub (Jan 13, 2020):
Some trackers add their own unique key to info hash so unless the metafile is redownloaded you cannot seed.
@FranciscoPombal
By different hash i meant if info hash is different then qBit treats them as different torrents. So the use case of skip hash checking applies when adding same torrents with different info hash
If they tick it knowingly but select a wrong directory.
Missing files thing would solve the issue.
@glassez
@FranciscoPombal commented on GitHub (Jan 13, 2020):
Just to be clear, I am not claiming it is prevalent. In fact, I hadn't thought about it until now.
A really determined cheater will always find a way cheat. But this seems to make it too easy.
@ghost commented on GitHub (Jan 18, 2020):
I think it doesn't matter if this issue is prevalent or not. A client by default should not have any feature which could be exploited so easily by a potential cheater. Like anyone could add a thousand torrents with skip hash check and seed those with zero effort and gain seedtime/seedbonus.
I understand that this issue is irrevalent for public tracker users but it's pretty critical for private trackers. This kind of exploitation could warrant a ban of Qbit from private trackers as well unless addressed properly.
@glassez commented on GitHub (Jan 18, 2020):
So, should we just drop it out?
@ghost commented on GitHub (Jan 19, 2020):
If the feature can't be made more difficult to be exploited then it's better to drop it I guess.
@glassez commented on GitHub (Jan 19, 2020):
It can more or less. But if it will be as expensive as a checking, it does not make sense.
@ghost commented on GitHub (Jan 19, 2020):
I think we have a less expensive way of doing it. Currently If a peer connects and libtorrent calls read piece and fails, that torrent resets to 0%.
If a torrent is added using skip hash, we could call read piece on a randomly selected piece which would emulate the same situation as a leecher connecting and requesting a piece from the seeder. Since libtorrent will fail to read the piece it’ll reset back to 0%. We’ll be reading just one random piece so this will be the least expensive way.
@ghost commented on GitHub (Jan 19, 2020):
I'm talking about this http://libtorrent.org/reference-Core.html#read_piece()
to be precise.
@FranciscoPombal commented on GitHub (Jan 19, 2020):
This + ensuring the directory structure exists seems like it could be a very robust way of preventing cheating in this way.
@glassez @arvidn thoughts?
@arvidn commented on GitHub (Jan 19, 2020):
My recollection is that in seed-mode, all files are verified to exist and have at least the size they're supposed to have.Oh, I guess this report is saying it isn't
@arvidn commented on GitHub (Jan 19, 2020):
@an0n666 you say "... libtorrent knows file doesn’t exists so it starts downloading it again. This is an unexpected behaviour."
When skipping hash checks, whether the files are verified to exist and have the correct size or not, there will always be a scenario where it turned out it wasn't seed. Maybe the files got corrupted or just weren't done downloading. If reverting to checking state is unexpected in that case, what behavior would you expect?
Libtorrent will still check the hash of each piece before uploading it to a peer, so under no circumstances will libtorrent upload corrupt data. In my mind that would be a serious problem.
Even though I agree that it would be reasonable to make sure all files exist and have the right size up-front, I don't really see why this is a problem. You use the word "exploited", what do you mean by that exactly? The swarm will not be fed corrupt data, so where's the exploit?
@ghost commented on GitHub (Jan 19, 2020):
The unexpected behaviour is qBit not checking if the files exist before adding the torrent in seeding mode. The rechecking and redownloading part is as expected.
By exploited I meant the state of seeding is not true and using such a state one can exploit seed time tracking or seedbonus systems found in private trackers. I’m not talking about peer to peer data exploitation.
@arvidn
@arvidn commented on GitHub (Jan 19, 2020):
I see. You can also just use
curlfor that, as long as trackers blindly trust peers.@FranciscoPombal commented on GitHub (Jan 19, 2020):
@arvidn
True, and that is a pretty low barrier of entry for cheating already, but being able to just tick a checkbox is just unreasonably low. Even extremely layman users can do it this way. IMO, the solution proposed above is reasonable from a cost/benefit standpoint in principle to prevent the extremely easy route.
@ghost commented on GitHub (Jan 28, 2020):
Why would I use curl when I can just tick a box and be done with it. Keep seeding for days or even months without actually downloading anything. Which one sounds more convenient to you?
Anyways...I think the maintainer is currently away so this "cheating" issue will probably go down the drain like many other issues out there.
@arvidn commented on GitHub (Jan 28, 2020):
The one that I can script and automate (i.e.
curl).@FranciscoPombal commented on GitHub (Jan 28, 2020):
The point isn't that using
curlis preferable to ticking a box, it's that it's still possible to achieve the same thing relatively easily, usingcurl. Making it impossible to tick the box in qBIttorrent doesn't fix the underlying exploit.Still, as I pointed out above, I still think it is a good idea to address this, since there is quite a big difference between "x can be exploited by ticking a box" vs "x can be exploited by scripting some HTTP requests (with
curl, for example)". The former makes it doable by a much wider range of users.@ghost commented on GitHub (Feb 20, 2020):
I accidentally closed the issue. Are we waiting for someone to look into this issue? Or nobody's interested.
@arvidn commented on GitHub (Feb 20, 2020):
I think the proposed "fix" for this is to make sure all files exist and have the correct size. Doing this unconditionally would have some cost, and I'm not super excited about taking on the maintenance burden of such logic. I think an approximation of this could be done from qbt by issuing one
torrent_handle::read_piece()call for a random piece. It wouldn't even have to care about the result. If that fails, libtorrent would put the torrent into a full-check mode, and check all pieces.@ghost commented on GitHub (Feb 22, 2020):
@arvidn looks like there's an issue with the method that you mention. When read_piece() is called on missing files it doesn't start the full-check mode. It only performs a full-check if the file is present. The torrent shows an error (The sys cant find the path ...) but as soon as you restart the client or pause/resume, the torrent starts seeding again without any recheck. Looks like qbt will have to handle the error alert.
@ghost commented on GitHub (Feb 23, 2020):
Another interesting thing is..torrents added in seed mode never give missing files error even if you rename or delete the files. Is this a bug or intended?
Edit: Seems like the seed mode flag stays in fastresume file. So on client restart it resumes seeding regardless of missing files or what not.
@arvidn commented on GitHub (Feb 23, 2020):
Sounds like a bug (or maybe several)
@ghost commented on GitHub (Feb 23, 2020):
My suspicion is that the seed mode flag stays in fast resume and it overrides all other errors when torrent is resumed/ client restarted.
@arvidn commented on GitHub (Feb 28, 2020):
I would encourage anyone with first hand knowledge about this problem to file a ticket against libtorrent describing the issue(s).