Re: Heads Up: cirrus-ci is shutting down June 1st

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Date: 2026-05-28 17:04:51
Message-ID: CAOYmi+ngJzXTnYvDinn4nq9pP-Xxv4ceLkhXrd7Lmv4J1ZWRtQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 28, 2026 at 9:13 AM Andres Freund <andres(at)anarazel(dot)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 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2026-05-28 17:06:22 Re: Heads Up: cirrus-ci is shutting down June 1st
Previous Message Daniel Gustafsson 2026-05-28 16:45:56 Re: new connection establishment (pgbench --connect) slow with pgbouncer due to libpq/OpenSSL global thread contention