public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jacob Champion <[email protected]>
To: Andres Freund <[email protected]>
Cc: Nazir Bilal Yavuz <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: [email protected]
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Date: Thu, 28 May 2026 10:04:51 -0700
Message-ID: <CAOYmi+ngJzXTnYvDinn4nq9pP-Xxv4ceLkhXrd7Lmv4J1ZWRtQ@mail.gmail.com> (raw)
In-Reply-To: <stjxvg6ghjbfceuhg4gzbmko6sbifbgrpya554jndrclijn56c@hvmzksnfuqf3>
References: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
<[email protected]>
<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>
On Thu, May 28, 2026 at 9:13 AM Andres Freund <[email protected]> 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 level
> 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 the
> 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 enabling
> 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 have
> > 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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
In-Reply-To: <CAOYmi+ngJzXTnYvDinn4nq9pP-Xxv4ceLkhXrd7Lmv4J1ZWRtQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox