'Jarvis' brings AI to the Linux command line, without Iron Man Welcome again to Repo Roundup, in which The Reg trawls online code repositories to let you know about the fun, the useful or the inexplicable. This week, let's start with DevSkim from Microsoft, which quietly landed in public preview in mid-December. DevSkim's aim is to help developers spot code errors that could be a …
... DevSkim would show a pop-up telling the user they're making a critical error
Maybe, maybe not. What if I'm aware of its shortcomings and decide that it doesn't matter in my case. For example, I could be using it in a program to de-dupe a filesystem, but I know that before hard-linking files together I'm going to do a bit-for-bit compare on them because I'm paranoid about accidental hash collisions and my own programming errors.
Right now, I wouldn't be too concerned about using MD5 in a HMAC (hash-based message authentication code) implementation. The Wikipedia page here states "attacks on HMAC-MD5 do not seem to indicate a practical vulnerability when used as a message authentication code." Likewise, I wouldn't be too concerned about using it in a Merkle tree implementation where hash collisions are only advisory (like the file de-dupe example above) or I have other explicit measures that prevent pre-image (or whatever) attacks.
In that case, why do the md5 comparison at all? If you're going to do a bit for bit comparison regardless?
I wouldn't use MD5 for anything, not because it's all that likely that there will be an issue today, but because code tends to live for a lot longer than we developers generally think.
For one thing, if it's a de-dupe problem, then it's much more efficient to use a hash of a file than to do a pairwise comparison of all files that could have the same contents. The problem of finding duplicates would be pretty intractable otherwise. Secondly, since the total number of duplicates will most likely be very small (compared to the full population) and the de-dupe step needs to be done only once. I can put up with a bit of extra overhead if it increases safety and finds me extra disk space.
As it happens, I actually use SHA-256 (using a tool similar to shatag in Debian), but notwithstanding that, I don't think that there's a problem using MD5 as a kind of heuristic to find identical files, so long as you have a second line of validation after it. In fact, you could use one or more different hashing functions as part of the validation step here, before you delete and create hard-linked copies...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
