Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122857
Date: Tue, 2 Apr 2024 14:36:27 +0100 (BST)
To: Jakub Zelenka <bukka@php.net>
cc: Marco Pivetta <ocramius@gmail.com>, Ben Ramsey <ben@benramsey.com>, 
    Bob Weinand <bobwei9@hotmail.com>, 
    Daniil Gentili <daniil.gentili@gmail.com>, 
    PHP Internals List <internals@lists.php.net>
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
In-Reply-To: <CAEKnhAGmDRMypM=fsWAroC6M6JcbwQRf7HYbb7n3GPNVQGvXjA@mail.gmail.com>
Message-ID: <95c92b6a-6788-fddb-a130-e4d122338b68@php.net>
References: <AM8P250MB01705B564C0F9B2F460F56B0E2392@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM> <9008050F-4EE1-4E19-B513-654602E118A7@benramsey.com> <CADyq6sLr=Zv0OmL55na0c6kGkaxvy9A8fJhptn71si8u7rzedQ@mail.gmail.com>
 <CAEKnhAGmDRMypM=fsWAroC6M6JcbwQRf7HYbb7n3GPNVQGvXjA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-600893831-1712064987=:14553"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-600893831-1712064987=:14553
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sat, 30 Mar 2024, Jakub Zelenka wrote:

> On Sat, Mar 30, 2024 at 7:08=E2=80=AFAM Marco Pivetta <ocramius@gmail.com=
> wrote:
> >
> > I understand that the XZ project had signed releases too: that still=20
> > means that downstream consumers would need to trust the release=20
> > managers anyway, and reproduce the whole chain themselves.
> >
> > I suppose that's part of OP's concern.
> >
> I agree that compromised RM is a problem that we should look into.
>=20
> We have been actually already discussing something similar. I have=20
> been thinking about it and it could be potentially used for all=20
> builds. The idea is that we would setup worklfow on CI that would run=20
> on tag push and it would call (authenticated https request)=20
> downloads.php.net server that could do the actual build, sign them and=20
> return the hashes to the CI job which would display them and do extra=20
> verification (probably its own build to verify that download server=20
> work as expected).

=2E..

> It needs more thinking to iron out all details and make sure it is a=20
> secure but I think it would be something worth to look at.

I don't mind coming up with an automated way, but we probably should not=20
use the *downloads* server. All it does is serve files. It has no=20
compiler or anything else. It's a storage optimised instance with little=20
CPU.

On CI we already test the builds, what does stop us from also just=20
having it make the tarball and attach it as an artefact? We can then=20
setup somethin gon the downloads server to pull these artefacts. In=20
fact, this is exactly what we're already hoping to do for Windows=20
downloads too. Having it all in one place is probably even better (and=20
easier).

Of course, having CI make the tarballs means we need to trust that CI=20
isn't compromised ;-).

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-600893831-1712064987=:14553--