Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

There is a breakdown in UX if your references need to look like this

SHA `11bd71901bbe5b1630ceea73d27597364c9af683`

That means absolutely nothing to a human being Whereas

> hashicorp/setup-terraform@v3

Is easy to understand.

How about

> hashicorp/setup-terraform!v3.0.1

This version, and only this version, fails if the version cannot be found.

Or

> hashicorp/setup-terraform@v3-2025-03-26-15-01

Give me the version of the library as it was at this specific time or fail if it can't be found

Presumably it would be wise to check the SHA as well to ensure no changes have taken place maliciously

One could go old school and import the code from the various needed libraries, into the main project. Now you have complete control over what runs and it can be audited and will be in a safe state until explicit action is taken to update the code.



This is rehashing (no pun intended) a very long-discussed issue about versioning. Your post also contradicts itself.

> SHA `11bd71901bbe5b1630ceea73d27597364c9af683` - That means absolutely nothing to a human being

> Presumably it would be wise to check the SHA as well to ensure no changes have taken place maliciously

That's exactly why the first one happens so often - I've checked the dependency at that version, and I want to make sure I only get that version, as spoofing sha's in a Git context is not part of my threat model.


That is true. In the post I am replying to the idea was

SHA `11bd71901bbe5b1630ceea73d27597364c9af683

as what the script contains as a reference. While i would advocate

hashicorp/setup-terraform@v3-2025-03-26-15-01 Hash: `11bd71901bbe5b1630ceea73d27597364c9af683`

I consider it easier to deal with, .




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: