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>
In-Reply-To: <qs2jmmyqlmvvj5jfhrkdo5q5fzfjulgiu3dqmgz4gvfscqi4vc@r5rvsrblxres>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 28 May 2026 08:51:09 -0700
Message-ID: 
 <CAOYmi+mpks_rE5E8fLzANbmhEySK=XC8rAtxi_qPVQKiu6nUGA@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%2Bmpks_rE5E8fLzANbmhEySK%3DXC8rAtxi_qPVQKiu6nUGA%40mail.gmail.com>
Precedence: bulk

On Thu, May 28, 2026 at 8:07=E2=80=AFAM Andres Freund <andres@anarazel.de> =
wrote:
> On 2026-05-27 15:15:46 -0700, Jacob Champion wrote:
> > - Do we need to defend our downstream forks from this workflow? (We
> > have 5,700 of them, apparently.)
>
> I don't see why. I think it's good if they run CI. Having forks not run C=
I by
> default would imo take one of the main advantages of using github actions
> away.

I was imagining a quick opt-in, like the Cirrus flow did, that fork
owners can do once they have checked their settings.

(I thought we planned to research medium-term alternatives to Actions
anyway; is it important that the entire graph starts running hundreds
or thousands of CI copies right away?)

> Yes, they are too permissive by default, including on postgres/postgres. =
 I
> think postgres/postgres isn't *that* threatened, but we should make thing=
s are
> shored up anyway. Where it's really crucial is the postgresql-cfbot repo.

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.

--Jacob