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

[Taylor Blau <ttaylorr@openai.com>]

On Fri, Oct 23, 2026 at 02:45:01PM -0700, Junio C Hamano wrote:
> 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