On Thu, Jun 11, 2026 at 6:09 AM Andres Freund <[email protected]> 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
