On Thu, Jun 11, 2026 at 6:09 AM Andres Freund <andres@anarazel.de> wrote:
> > 1) It depends on whether you think it's as easy to poison upstream
> > MSYS servers as it is to poison a mutable GitHub tag.
>
> It's just as easy I think.
Okay. In that case it's probably not as useful to pin this, when
compared to the pg-vm-images alternative.
> I think you maybe understimate the noise of constant "bump version of xzy"
> commits across N branches.
Even if our MinGW setup action needs to be constantly on the
leading-edge, it released roughly once a quarter last year. (But I'd
say just update it when there's a security alert, or else switch to
pg-vm-images, to both speed things up and control the
reproducibility.)
> I guess I just don't see the supply chain danger here. This is for testing,
> not for making releases. What's the threat model in which attacking postgres'
> CI helps you spread the attack further?
Well, we went through a similar conversation upthread -- if no one
ever makes mistakes in the token permissions, and no one ever does
anything odd in a downstream fork, and GitHub doesn't turn out to have
a corner case that lets you escalate from a read-only token in an
unintuitive way, then I guess we're probably fine?
It's just a lot of 'if's, and the cost of pinning a single SHA really
didn't seem to outweigh all that to me, since GitHub has a bunch of
tools like dependabot that assist people who are pinning SHAs.
--Jacob
