@Yglorba

Good question. I guess people thought naively that .sfv files were enough, but of course that’s not true.

Some .nfo files contain md5s for things, but that would be easily changeable.

It would have to be a cryptographic checksum, using something like GPG/PGP with a distributed fingerprint to be any good.

I’ve seen one or two over the years, but not as many as you’d expect for people that should be worried about security and image.

Modern scene dosn’t even require strict .nfo files. Most TV groups in WEB or HDTV sections just add basic metainfo and maybe imdb link and barely include any nice ASCII art. Only the oldest and best groups do ASCII art nfo files with all kinds of useful info inside. However all scene groups are required to include .sfv rar checksum files. I’ve never seen any p2p groups do this. Most p2p groups .nfo files are forum html of mediainfo. But when scene releases leak to public and unrared files like .sfv are deleted most of the time by uploaders. So within the scene checsums work as they should, in public not so much. But there is sites like srrDB.com that you can use and most of there .nfo posts for .srr files also include .sfv files.

I’ve noticed some scene game/software releases have blake3 hashes now. That doesn’t account for everything else, but I’d say it’s a good step.

New Lemmy Post: Why don’t nfo files contain a checksum for the release? (https://lemmy.dbzer0.com/post/9923312)
Tagging: #Piracy

(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)

I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md

What is a .sfv file some mention here?

This frustrates me to to no end. sometimes the only ISO I find is very sketchy and I end up downloading a trusted repack instead.

I agree that this would be handy as hell, but I have some guesses why it is rarely ever done.

1. The majority of people (both uploaders and downloaders alike) are lazy and don’t bother with checksums. I would even guess that the majority of people who pirate probably don’t even know what checksums even are.
2. In terms of validating the transfer, some P2P protocols like bittorrent have an internal validation method so any checksums manually validated by the user would be redundant. Obviously, this does not apply to all pirate sources like DDL etc but it definitely would make people leaning towards the reason #1 (laziness) camp feel justified.
3. In terms of security, it would be easy as hell for a malicious party to generate a new torrent or new download with a new checksum. In some cases, like a single site controlled by the (re-)packer (e.g. like fitgirl for example), having a checksum on the site would still be beneficial to those that check since it would also help to identify frauds. That said, most of the people who run into problems with that kind of thing do so bc they didn’t read up on things and got the torrent from unofficial sources (e.g. the people it would help the most probably either don’t know about checksums or wouldn’t bother to check). Still, if release groups were going to start doing checksums, I seriously would hope that they were not only putting them into the NFO files.
4. For the more secure checksum algorithms like SHA-256 and SHA-512, they can take awhile to generate on large files like an umpteen plus GiB game. Maybe not a big deal if you are just doing it once, but if you a releasing a lot of stuff, the extra time would definitely be noticeable and add more work to the release process. Which is going to push a few more people into the reason #1 (laziness) camp.
5. Sometimes there are multiple revisions or other variations (like Some Cool Game v3.14 vs Some Cool Game v3.16 or Some Cool Game with DLC edition) as well as potentially having multiple sources (Some Cool Game GOG version vs Some Cool Game Steam version vs Some Cool Game dvd version) - since each and every one of these combinations would need a new checksum, you’re basically in the same boat as point 4.
6. There are groups such as rightsholders, malware creators, antivirus companies, and so on that have a vested interest in you either downloading fakes, installing malware, or having a real risk of malware. Probably only the first 2 groups would potentially be creating pirate releases but I doubt they’d intentionally make it easier to discover what they’re really up to.
7. If the checksum were provided on the website, in theory, that would indicate that whoever generated the checksum had downloaded the file. So there could potentially be some legal foothold to use against a website that was providing the checksum. Maybe, nothing. And maybe that would just be something like a takedown letter (kinda like how links are treated today). But maybe something worse like site owner being liable to be sued / fined / imprisoned. Idk, I’m not a lawyer. Plus if a site was just copying whatever was in the NFO file, that would be worthless for security by way of point # 3 (e.g. anybody could make a new download with a modified file + modified checksum).
8. There are multiple checksum algorithms. No matter which one they pick, somebody somewhere will bitch about it. SHA-1 / MD5: “those aren’t secure; you should use SHA-256 at least”. SHA-256 / SHA-512: “this is slow and the random numbers are really long. wHy dOn;T u jUsT uSe md5?” or “u sHoUld uSe sTanDarD wiNdOws uTiLitiEz”. Any checksum: “wish you’d stop bothering with checksums and just release faster” and so on

The SFV file contains checksums.