bugmake - Bugs: bug #61594, suggest new $(hash ...) function


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

Submitter:  None
Submitted:  Wed 01 Dec 2021 04:36:41 AM UTC
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.4 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Sun 05 Dec 2021 10:07:03 PM UTC, comment #3: 

To add my concern regarding integrating cryptographic hashes into GNU Make relate specifically to import restrictions of some of these hashes to a large number of countries. Searching on Cryptographic Import Restrictions will explain this. Having user selectable hashes through the load function would decouple any restrictions that would otherwise be imposed and limit the ability to use GNU Make; however, I would caution that using these functions in Open Source projects would transitively limit or confuse the ability to build those projects if the hash functions are unknown or not available.

Randall S. Becker <rsbecker>
Sun 05 Dec 2021 08:41:18 PM UTC, comment #2: 

It's a bit confusing because the "good and useful points" were all made in responses to the mailing list, not posted to this Savannah issue.

In any event, I don't see any point in using any sort of cryptographic hash, even one as widely available as SHA-1.  All that's wanted here, from my understanding, is a value which is highly likely to be unique.  It seems that something like xxhash or the GNU hash-pjw function would suffice.  These, however, give results that are only 4 or 8 bytes wide as opposed to something like 16 bytes for MD5 or 20 bytes for SHA-1.

I don't know if these extra bytes are worth the cost.

In any event any such function would need to allow a way to choose the type of hash to avoid lock-in: we wouldn't want to just have "$(hash <somestring>)" then never be able to change it, I wouldn't expect.

Paul D. Smith <psmith>
Group administrator
Wed 01 Dec 2021 02:42:00 PM UTC, comment #1: 

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.

Wed 01 Dec 2021 04:36:41 AM UTC, original submission:  

Historically there's been a certain amount of resistance to adding new native functions to GNU make but a few have come in lately so ... I wonder if the idea of providing a hashing function has been considered?

I'm not thinking of a cryptographically secure hash, just something that could be used as a convenient digital signature. The use case I'm thinking of in particular is the advanced topic of forcing rebuild on command-line changes, which of course requires stashing the previous command line for comparison. Unfortunately, in some cases command lines can be very long and ugly; in our case they're >2K chars apiece. Stashing these can be done, and in fact we do it, but it would be much nicer and simpler if a SHA-1 or similar signature could be stashed instead.

It seems relatively easy to implement and document, assuming the GNU hashing functions are available somehow. The question in my mind, if it was to go forward, would be whether to give it a specific name and nail down the algorithm, such as $(sha-3,$(data)), or a generic name like $(hash,$(data)). Historically every hashing algorithm has been superseded by a better one every few years, which argues for $(hash ...), but on the other hand it's not intended for security anyway so anything with a sufficiently infinitesimal collision rate would be fine and there might be value in being able to generate a known hash like SHA-1.

Just a thought. Close with prejudice if not interested.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rsbecker (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code