Re:How does rsync work?
by naniwaduni on Saturday July 02, 2022 @10:42AM
(#31959384)
> * User has maliciously modified file and set mtime back. Since it's MD5 (broken), the malicious user can make the checksum match too. checksumming doesn't help.
No, md5 is not broken like that (yet). There is no nkown second-preimage attack against md5; the practical collision vulns only affect cases where an attack controls the file content both before and after update.
The very existence of filesystem checksumming is because your first point isn't always true.
Also, filesystem checksumming does not guard against ram/kernel-bugs. On top of that file system checksumming is very rare.
It has its use: I discovered corruption in files copied between external hard drives over a USB hub, using checksum. It was a bad hub, hasn't happened again since I changed it (finding it once got me paranoid enough to check every once in a while).
For anyone curious about how to find such problems without changing the files, I used "--checksum --dry-run --itemize-changes"
* Underlying disk device corruption - but modern disks do internal error checking, and should emit an IO error.
* Corruption in RAM/software bug in the kernel IO subsystem. Should be detected by filesystem checksumming.
* User has accidentally modified file and set mtime back. fixes this case.
* User has maliciously modified file and set mtime back. Since it's MD5 (broken), the malicious user can make the checksum match too. checksumming doesn't help.
Given that, I see no users who really benefit from checksumming. It isn't sufficient for anyone with really high data integrity requirements, while also being overkill for typical usecases.