bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bug #61594] suggest new $(hash ...) function


From: rsbecker
Subject: RE: [bug #61594] suggest new $(hash ...) function
Date: Wed, 1 Dec 2021 10:05:21 -0500

On December 1, 2021 9:42 AM, anonymous wrote:
> 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.

I provided git as an example, not as a requirement. Anything could be used even 
something that the local team may have written to perform their hash. Even a 
very old SWID might work, which I think is not subject to restrictions anymore. 
If git is available (somehow), it is not the problem of the GNU Make team of 
those importing it. I'm sorry for mentioning git, but it is only an example, 
and a red herring, apparently.

Sadly, the import restrictions do not distinguish between message digests and 
cryptography since MDs are used for one-directional password encryption. Hash 
functions are different than message digests. Some message digests are hashes, 
but not all hash functions are message digests. f(x) = x % 113 is (arguably I 
suppose) not a message digest. Similarly, not all message digests are 
bi-directional cryptographic functions - but I don't think governments have all 
caught up with that point.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]