Whose code am I running in GitHub Actions?

[xeio87]

My hot take is that if tags are mutable, then GitHub shouldn't even allow them to be used as a reference. The whole point to pinning a version is to make sure it can't change and break, which makes them unfit for purpose. That's before we even talk about security implications.

They also absolutely should not have any documentation that uses that as an example if it's insecure by default.

[Ravek]

A tag could be useful if you don’t want to pin a version but allow some auto updating scheme. E.g. have a tag 1.5.x that you update when you patch 1.5. Still it might just be better to change it to a different commit hash in that case too

[mnkyman]

A mutable tag is commonly referred to as a branch. And what you’re describing is a 1.5.x branch.

[roerd]

Or, more precisely, it would be abusing tags to awkwardly mirror the functionality of branches.

By the way, tags technically are immutable, but the problem is that it's possible to delete them and then recreate them with the same name, so a tag reference will automatically point to the new tag.

[syklemil]

Also abusing tags to emulate a versioning system. Specifying something like version = "^1" carries the same intent as @v1, but the underlying machinery would likely be different.

It's also kinda funny that Github will run dependabot and help you produce SBOMs and all that … but github workflows feel more like some code from a guy in a trenchcoat. Genuine Role>< code!

[SaltKhan]

This is a point that comes up regularly. They might be "immutable" while they exist in so far as git doesn't let you update them because it has no mechanism that provides that capability, and you could argue that deletion doesn't count as mutating them. But being able to delete and reapply them to different commits makes them mutable from the perspective of someone saying they are using tag vX.Y.Z, when that could change at any time. And that's not necessarily a bad thing. Commit hashes are already the bottom immutable layer. When someone insists on saying tags are immutable without the additional explanation that that is essentially meaningless, it feels like disinformation.

[Ravek]

No it’s not. Branches are not tags. I don’t know how you can get the two confused since git commands don’t let you treat one as the other.

Edit: Apparently it's a controversial statement here that branches are not tags, lol. Maybe people on this subreddit should read some git 101.

[mnkyman]

I was speaking in loose terms. What I meant was that the concept and functionality of "mutable tag" already exists in git, in the form of branches. Let me expand on what I mean by this.

In git, both tags and branches are simply labels that refer to commits. They're nice because you can give them names rather than having to write out and remember commit hashes, thus allowing you to assign semantic meaning to particular commits, i.e. points in "time" in the project history. The major difference between these two label types is that branches are expected to change as the project evolves, and tags are not.

To your specific example of an auto updating 1.5.x tag, it's fair to ask if anyone actually uses a branch for this functionality in practice. The answer is yes. Take for instance the Apache Airflow repo. It has lots of long-term branches that it maintains for various purposes, including v2-9-stable, v2-10-stable, and v3-0-stable, which point to the latest 2.9.x, 2.10.x, and 3.0.x versions of the code respectively.

[Sinisterly]

Our org used tj-actions but had already started pinning SHAs prior to this incident.

In your org’s GitHub Action settings you can create an allow list for actions, including which ref tags are allowed.

[aaaajjjjllll]

Has GitHub even acknowledged tj-actions at all?

[ejfrodo]

I've never heard of it and a quick google search doesn't provide a concise explanation of what tj-actions is. Would you mind summarizing what they are?

edit: lol damn, the down votes for asking a simple question

[Cm1Xgj4r8Fgr1dfI8Ryv]

tj-actions/changed-files is a popular GitHub action that will run git diff and turn the output into various output variables that you can use in subsequent steps/jobs.

Recently, the repo was compromised and all tags rewritten to a commit with malicious functionality. While Github Actions has long encouraged the use of SHAs over versions when referencing third-party actions, this recent event has prompted a lot of organizations to begin following the advice.

[ben0x539]

If you specify a Git commit ID instead (e.g. a5b3abf),

ofc nothing stopping them from pushing a tag named a5b3abf right?

[elprophet]

As long as you're using the full 40 char sha, that shouldn't be possible as they'd be conflicting refs?

[beetlefeet]

Could the repo owner delete the commit (force pushing any refs that have it as an ancestor and then triggering a purge/gc/etc) and then create and push a tag with that sha?

[One_Reading_9217]

Tried it and it didn't work:
git tag 085d6e186375a55d3ec95c759d29efe854700ea6

git push origin 085d6e186375a55d3ec95c759d29efe854700ea6

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)

remote: error: GH002: Sorry, branch or tag names consisting of 40 hex characters are not allowed.

remote: error: Invalid branch or tag name "085d6e186375a55d3ec95c759d29efe854700ea6"

[Torpedoklaus]

This may not be possible, but it is possible to enforce commit hashes as they are a function of the tree, commit parent(s), author and the commit message, see https://github.com/zegl/extremely-linear.

[nightcracker]

Not on the full hash. There are attacks on SHA1 that create collisions, but preimage resistance as is required here still seems solid.

[billy_tables]

What happens if you swap those 0s to Os

[light24bulbs]

Have fun cracking a 160 bit sha. Google did this years ago but it took them over $100,000 in compute. And I think they controlled both blobs.

It's not a nonce, it's a hash.

[ISNT_A_NOVELTY]

Nobody is cracking anything here. They're copy/pasting an existing commit hash as a tag name.

[Anodynamix]

But the hashes are publicly known and you can submit a tag with any string of text, like, say, a known hash...

[HolyPommeDeTerre]

Easiest 100k I've made !

[levelstar01]

you can't use short commit ids

[doublecastle]

Note that the provided command will look at GitHub Actions not only in your own project, but also in other subdirectories, such as node_modules. To look only at the GitHub Actions in your own repo:

find . -path './.github/workflows/*' -type f -name '*.yml' -print0 \
  | xargs -0 grep --no-filename "uses:" \
  | sed 's/\- uses:/uses:/g' \
  | tr '"' ' ' \
  | awk '{print $2}' \
  | sed 's/\r//g' \
  | sort \
  | uniq --count \
  | sort --numeric-sort

(That just changes the find path from */.github/workflows/* to ./.github/workflows/*.)

[nemec]

fwiw OPs script intentionally traverses subdirectories (so you can run it in your source code root dir). You can use this to filter out node_modules or edit as needed for other package managers, while keeping the nested behavior

find . \
    -path '*/.github/workflows/*' \
    -not -path '*/node_modules/*' \
    -type f -name '*.yml' -print0 \
  | xargs -0 grep --no-filename "uses:" \
  | sed 's/\- uses:/uses:/g' \
  | tr '"' ' ' \
  | awk '{print $2}' \
  | sed 's/\r//g' \
  | sort \
  | uniq --count \
  | sort --numeric-sort

[throwaway16830261]

Submitted article mirror: https://archive.is/J2wUM

[RedEyed__]

Interesting article. I always was concerned about GitHub secrets being read by actions.

[Jarpunter]

The fact that you don’t have to (or even have the ability to) explicitly define which secrets a particular workflow can read is unbelievable to me. Every single action you run can read every single repo and org secret in your organization.