Follow-up Comment #1, bug #61594 (project make): These are all good and useful points, thanks. However, some counter-arguments: I tried to be careful to distinguish "cryptographic" from "low-collision-rate-hash" in the original description because I absolutely do not want to "introduce cryptography to GNU make". It's unfortunate that the two concepts tend to be implemented by the same algorithms and subject to the same license and export rules but they remain logically different. Thus, while accepting that things like export restrictions might need to be considered, I suggest we elide terms like 'cryptography' from this discussion because it's just about a hash.
My first counter-argument comes from the "$(shell git hash-object obj)" suggestion which begs the question: if git, which relies heavily upon SHA-1, is available, doesn't that mean SHA-1 is also natively available? I'm not aware of git being restricted in any jurisdictions. It's certainly not my area of expertise but I've never heard of export restrictions being an issue in git which seems to have spread everywhere. Second counter-argument: hashing algorithms cover a spectrum from original checksum to the latest super-secure hash whatever that is today. GNU make itself must have a hashing function built in - after all, you can't have a hash table without a hash function. So it seems likely that there's a sweet spot on this spectrum, some function which is both unrestricted and has a sufficiently low collision rate, to do the job. However, having made the suggestion I'm happy to let Paul dispose of it as he likes. For my own purposes I'll probably look at the loadable module since the shell is creaky and slow. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?61594> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/