MIME-Version: 1.0
References: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
 <DIM49A100EY1.2YFS2A6WAI3ZJ@jeltef.nl>
 <CAN55FZ30Np67cATsqYxF1SsP598VoRv4hJQZ4w9RA3Qe55prnQ@mail.gmail.com>
 <CAN55FZ13uX0cLSbgtSnnFeh5sTLeMr7+8UzmqpU6QjOtrRJTLg@mail.gmail.com>
 <qe4lh2i5di2gh7bxkbfisifaohrvyfukbybwxwzxdnll45hnt3@luod7i2mon67>
 <CAOYmi+n8RRmtGUr_fZkYzX5XbGH5+Q0c1M1XMr7ytXbRs1JxJA@mail.gmail.com>
 <qs2jmmyqlmvvj5jfhrkdo5q5fzfjulgiu3dqmgz4gvfscqi4vc@r5rvsrblxres>
 <CAOYmi+mpks_rE5E8fLzANbmhEySK=XC8rAtxi_qPVQKiu6nUGA@mail.gmail.com>
 <stjxvg6ghjbfceuhg4gzbmko6sbifbgrpya554jndrclijn56c@hvmzksnfuqf3>
In-Reply-To: <stjxvg6ghjbfceuhg4gzbmko6sbifbgrpya554jndrclijn56c@hvmzksnfuqf3>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 28 May 2026 10:04:51 -0700
Message-ID: 
 <CAOYmi+ngJzXTnYvDinn4nq9pP-Xxv4ceLkhXrd7Lmv4J1ZWRtQ@mail.gmail.com>
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
To: Andres Freund <andres@anarazel.de>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
 Jelte Fennema-Nio <postgres@jeltef.nl>,
	Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BngJzXTnYvDinn4nq9pP-Xxv4ceLkhXrd7Lmv4J1ZWRtQ%40mail.gmail.com>
Precedence: bulk

On Thu, May 28, 2026 at 9:13=E2=80=AFAM Andres Freund <andres@anarazel.de> =
wrote:
> On 2026-05-28 08:51:09 -0700, Jacob Champion wrote:
> > I was imagining a quick opt-in, like the Cirrus flow did, that fork
> > owners can do once they have checked their settings.
>
> I'm not aware of a good way to do that.  I'm sure we could hack up a way,
> e.g. by requiring an environment variable to be configured on the repo le=
vel
> to opt-in,

That was more or less my thought.

> but it seems pretty crufty.
>
> I think making it easier for forks to run CI is a far bigger gain than th=
e
> risk of GHA doing something stupid in a fork.  There were a lot of folks =
that
> didn't realize that they could run CI individually or had a hard time ena=
bling
> it.

Right, but Cirrus only ever had the ability to run a CI, not write to
the code base it was running. If we unleash a bunch of newcomer GitHub
CIs without first explaining "hey, you really need to lock some stuff
down first", I think we may be doing them all a disservice.

Especially since GitHub claims to protect downstream forks from this
[1] -- which is undocumented? -- but that protection appears to not
actually work [2] if we push a workflow at the root of the graph. (I
haven't verified any of that myself yet, but in the absence of
documentation, I'm not really optimistic.)

> > Combining with the above: I'm worried that if all of our 5.7k forks hav=
e
> > permissive settings, and we accidentally ship a workflow vulnerability =
that
> > doesn't affect us but does affect them, that would not be a fun cleanup=
.
>
> I'm not sure what path for that would exist that don't already?

Using the current v2 patch, for instance, a `actions: write` token
that gets leaked by accident can then be used to approve pending
workflow runs. (Consensus seems to be forming that we shouldn't have
those privileges in the workflow spec, but we have to all remember why
that rule exists when we're reviewing workflow patches.)

--Jacob

[1] https://github.com/github/docs/issues/15761
[2] https://github.com/orgs/community/discussions/53510