[8.51] Verify Checksums doesn't report wrong SHA-256

[davy]

Issues with wrong check sums of SHA-256 aren't reported by the UI.
Works for md5 as a charme.

Steps to reproduce:
1. create a check sum of SHA-256 type for any file.
2. verify check sum -> ok
3. modify check sum file manually and re-run verify check sum.
You'll see that the return values are always "OK" even though obviously the content was garbled.

[ghisler(Author)]

NOT confirmed. I changed the checksum (or changed the file), and I get error that CRC is wrong.

Can you give me more details of what you changed?

[Dalai]

I can confirm this partly, although I'm totally unsure whether this is to be expected. Removing characters from the checksum, i.e. changing its length, still verifies the files as OK. This is true for all checksum types, although TC prints

Code: Select all

Errors: 0
OK: 0, not found: 0, read error: 0, wrong checksum: 0

So TC didn't verify any checksum, did it?

Changing any byte of the checksum (keeping the checksum's length) fails the verification, though.

Regards
Dalai

[davy]

Yes exactly, I added some character in front of the checksum, and played with the positioning of the file name within the sha file (Carriage return vs. not). In none of my scenarios TC detected the error.

[ghisler(Author)]

No it doesn't. TC looks at the length of the checksum, and only uses it if there is a matching length. As the results shows, there are 0 errors, but also 0 files OK, which means that TC did not see any valid checksums at all.

[Dalai]

As the results shows, there are 0 errors, but also 0 files OK, which means that TC did not see any valid checksums at all.

Well, then TC should say so in a more prominent way, don't you think? Right now TC requires you to read the result line really carefully because there's no warning or error and no color. I suggest you append a warning in a different color (e.g. yellow) saying "No checksums found/verified" or something like that.

Regards
Dalai

[Hacker]

Christian,

TC looks at the length of the checksum, and only uses it if there is a matching length. As the results shows, there are 0 errors, but also 0 files OK, which means that TC did not see any valid checksums at all.

Ah, that's not optimal. In case I have a file with 2587 checksums and one of them is bad, I'll never know unless I count the lines in the file and compare it with the sum of the results.

Roman

[Dalai]

Indeed. And I didn't think of that.

So, TC should show some information about invalid checksums in the results - at least when there are any invalid ones.

Regards
Dalai

[ghisler(Author)]

How realistic is it that there is a checksum with the wrong number of digits? This doesn't happen, even when the file is corrupted - only when you edit the file manually.

[Dalai]

Yes, it's unlikely to have corrupted checksum files. But IMO TC should handle as many errors as possible, at least at verifying checksums. As Hacker pointed out, you'll never know that you have corrupted files, since TC didn't check them and didn't complain about any wrong checksums.

Regards
Dalai

[Hacker]

Christian,

How realistic is it that there is a checksum with the wrong number of digits? This doesn't happen, even when the file is corrupted - only when you edit the file manually.

Very simple - I copy/paste the checksum from a website to verify a download but accidentally miss the first character when selecting.

Roman

[Dalai]

2Hacker
I thought about that, too. However, that's not a problem since TC just shows "Please select only SFV, MD5 or SHA files!" in such a case. So the user gets some feedback immediately.

But I still think it's unfortunate that TC doesn't care to notify the user about wrong checksums in the checksum files...

Regards
Dalai

[Hacker]

Dalai,
Huh? You must be talking about some different situation. Steps to reproduce:
- have a file
- have its checksum and name
- copy checksum (minus one character) and the file's name into the clipboard and paste it into a file named eg. downloadedfile.md5
- run the .md5 file -> no error

Roman

[Dalai]

You're doing it wrong . Just kidding. I thought you mean it like this:

• have a file
• have its checksum and name already in the clipboard (from a website or whatever)
• Use menu Files > Verify Checksums

If the checksum has the correct length, TC will verify it. If the checksum is of a wrong length, TC will not check it and instead show above message. Of course, if you go the longer (and obvious) way of pasting the checksum into a checksum file, then TC will not check it, if the checksum's length is wrong. And that's what is unfortunate, indeed, and it should be improved.

Regards
Dalai

[ghisler(Author)]

The problem is that these checksum files could contain comments, file details like size/time, and multiple checksum types where TC only supports some of them. Should I really show an error for each line not recognized by TC?