[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.