(I’d prefer to not link any specific PRs) I noticed a recent pacakge build failure due to upstream hash change. From the public discussion/PR I can see, we simply updated the hash and merged it.
In the light of recent concerns around supply chain integrity, what would be the right way to handle these situations?
In this particular case, it was source from fetchFromGitHub and a tag reference. I would not normally expect this hash to change, outside of some change in GitHub’s exposure of these sources, or upstream moving a tag. The latter raises a bit of an eyebrow for me.
random thought: It would be nice to somehow know what exact commit was being built, with this tag reference, when this was initially merged.
Even more eye-brow raising: @r-ryantm sent two different PRs for this same upgrade, indeed with different hashes. (this was not accurate, I got caught by very similar package names).
EDIT: In the meantime, I’ve asked upstream in this particular case, if they moved the tag.
To me, seeing a version bump without a hash change indicates a “problem” (usually just a forgetful mistake, mostly). Similarly, a hash bump without any change to the declared source being fetched indicates, at the very least, an oddity.
Presumably we bias towards using version tags or stable git commit refs because we expect the output hash to remain constant for what is presumably a static, reliable “reference”.
The problem is that many upstreams consider it OK to move a git tag, at least if it’s soon after creating it. (I’m against that, and IMO it’s against the design of git.)
EDIT: it certainly is “suspicious” when the hash changes, but a malicious actor (like in case like xz) can rather just create a new release or something more natural.
Though I fully agree that moving a tag after release is bad practise, I’d question if that is an indication of malicious activity. And on a different note, these things are always case-by-case decisions, so it’s hard to say if the decision was appropriate if you refuse to link the concrete PRs.
I normally shrug off upstream hash changes and update to match the reality… but this «normally» is also the same «normally» as upstreams normally posting a quick «sorry, messed up a release, this is what still needed to be changed» remark somewhere.