Re: [PATCH] ci: pin actions in the main workflow to full commit IDs

From: Taylor Blau <ttaylorr@openai.com>
Date: Oct 24, 2026, 00:32 UTC
Message-ID: <atv8gYf8Le1WHTA0@com-79390>
In-Reply-To: <xmqqbj8k3xcy.fsf@gitster.g>

On Fri, Oct 23, 2026 at 02:45:01PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> Taylor Blau <ttaylorr@openai.com> writes:
>
> > Some forks are hosted by organizations that restrict which GitHub
> > Actions may run, including requiring actions to be pinned to full
> > commit IDs. Our main CI workflow refers to actions by version tags or
> > branches, which prevents it from running under such a policy.
>
> I do not see why the limitations of other organizations should
> affect our workflow here.  What if another organization prefers
> readable and concise tag names?  Would they send a patch to revert
> this change, leading to a "last one wins" situation?

I see what you're saying, but I think in this particular case there *is* a good reason to do this in your tree.

These actions are executable dependencies of our CI, so if a malicious actor points, say, checkout@v6 at something which modifies code in the tree, we are relying entirely on the permissions of CI's configured $GITHUB_TOKEN to save us from code injection.

There is maintenance involved, including deliberately picking up bug and security fixes within a major version. But using a tag does not eliminate the decision about which code to execute; it delegates that decision to whoever can update the tag. I think making those updates explicit in our repository is worth the maintenance.

Keeping a downstream patch is certainly possible. But having each fork repeat the same translation leaves the upstream workflow without that protection and duplicates the work. That is why I think this belongs upstream.

I think that we could reword the commit message to explain that benefit more clearly, but I do think this is the right policy.

> Would it be too much trouble for organizations with this specific
> requirement to maintain such changes in their own forks?

Just as a concrete example, before submitting patches out of openai/git, I apply this patch on top of my branch, then run CI, and then remove the extraneous commit before sending. This happens on every topic, and AFAICT this is not an uncommon restriction among other corporate organization accounts on GitHub.

Thanks, Taylor