Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122869
Precedence: bulk
MIME-Version: 1.0
References: <AM8P250MB01705B564C0F9B2F460F56B0E2392@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <9008050F-4EE1-4E19-B513-654602E118A7@benramsey.com> <CADyq6sLr=Zv0OmL55na0c6kGkaxvy9A8fJhptn71si8u7rzedQ@mail.gmail.com>
 <CAEKnhAGmDRMypM=fsWAroC6M6JcbwQRf7HYbb7n3GPNVQGvXjA@mail.gmail.com>
 <95c92b6a-6788-fddb-a130-e4d122338b68@php.net> <CAEKnhAG4AYy9wPzuVq3y_hqfjcWMDi8HtCkVQyL9Txoqogwz7A@mail.gmail.com>
 <CAO__Xv7=31W8FQgJ8xTokzA_qu0wo0bcVfOC7dKTMGGeOxmAhA@mail.gmail.com> <CAEKnhAEtuiQZ_7TpkwcONCeJ4=nOB-_UCHoJ+ojO1tGVNCmcWw@mail.gmail.com>
In-Reply-To: <CAEKnhAEtuiQZ_7TpkwcONCeJ4=nOB-_UCHoJ+ojO1tGVNCmcWw@mail.gmail.com>
Date: Tue, 2 Apr 2024 16:47:42 +0200
Message-ID: <CAJpLVh2qVLHwhg1+iPdxLWvZFgjZkL9-cjQxLwxLkMFsGjXu7Q@mail.gmail.com>
Subject: Re: [PHP-DEV] Consider removing autogenerated files from tarballs
To: Jakub Zelenka <bukka@php.net>
Cc: tag Knife <fenniclog@gmail.com>, Derick Rethans <derick@php.net>, 
	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>
Content-Type: multipart/alternative; boundary="000000000000e7d49506151e3012"
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

--000000000000e7d49506151e3012
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

internals+unsubscribe@lists.php.net -  550 5.7.1 Looks like spam to me.

Can't unsub...?

Den tis 2 apr. 2024 kl 16:46 skrev Jakub Zelenka <bukka@php.net>:

> On Tue, Apr 2, 2024 at 3:35=E2=80=AFPM tag Knife <fenniclog@gmail.com> wr=
ote:
>
>>
>> On Tue, 2 Apr 2024 at 14:53, Jakub Zelenka <bukka@php.net> wrote:
>>
>>> We will still need RM to sign the build so ideally we should make it
>>> reproducible so RM can verify that CI produced expected build and then =
sign
>>> it and just upload the signatures (not sure if we actually need signatu=
re
>>> uploaded or if they are used just in announcements).
>>>
>>> I think this should then prevent compromise of the RM and CI unless CI
>>> is compromised by RM, of course, but that should be very unlikely.
>>>
>>> Regards
>>>
>>> Jakub
>>>
>>>
>> On the side of the CI being compromised, this does happen, typically wit=
h
>> authed
>> private hosted CI, like jenkins. But if its open and accessible to
>> everyone to monitor, such
>> as github actions, everyone can monitor and audit the build logs to
>> verify the commands
>> ran and nothing unexpected happened during build.
>>
>> That is something PHP is missing atm, no one can verify the build proces=
s
>> for releases.
>>
>
> Yes that's what I was suggesting. This should be done by RM. In that way,
> the RM becomes more someone that verifies the build and not the actual
> person that provides the build.
>
> Regards
>
> Jakub
>
>
>

--000000000000e7d49506151e3012
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><a href=3D"mailto:internals%2Bunsubscribe@lists.php.n=
et">internals+unsubscribe@lists.php.net</a> - =C2=A0550 5.7.1 Looks like sp=
am to me.</div><div><br></div><div>Can&#39;t unsub...? <br></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Den tis 2 =
apr. 2024 kl 16:46 skrev Jakub Zelenka &lt;<a href=3D"mailto:bukka@php.net"=
>bukka@php.net</a>&gt;:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Tue, Apr 2, 2024 at 3:35=E2=80=
=AFPM tag Knife &lt;<a href=3D"mailto:fenniclog@gmail.com" target=3D"_blank=
">fenniclog@gmail.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 2 Apr 20=
24 at 14:53, Jakub Zelenka &lt;<a href=3D"mailto:bukka@php.net" target=3D"_=
blank">bukka@php.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>We wil=
l still need RM to sign the build so ideally we should make it reproducible=
 so RM can verify that CI produced expected build and then sign it and just=
 upload the signatures (not sure if we actually need signature uploaded or =
if they are used just in announcements).</div><div><br></div><div>I think t=
his should then prevent compromise of the RM and CI unless CI is compromise=
d by RM, of course, but that should be very unlikely.<br></div><div><br></d=
iv><div>Regards</div><div><br></div><div>Jakub<br><br></div></div></div></b=
lockquote><div><br></div><div></div><div>On the side of the CI being compro=
mised, this does happen, typically with authed=C2=A0</div><div>private host=
ed CI, like jenkins. But if its open and accessible to everyone to monitor,=
 such</div><div>as github actions, everyone can monitor and audit the build=
 logs to verify the commands</div><div>ran and nothing unexpected happened =
during build.</div><div><br></div><div>That is something PHP is missing atm=
, no one can verify the build process for releases.<br></div></div></div></=
blockquote><div><br></div><div>Yes that&#39;s what I was suggesting. This s=
hould be done by RM. In that way, the RM becomes more someone that verifies=
 the build and not the actual person that provides the build.</div><div><br=
></div><div>Regards</div><div><br></div><div>Jakub</div><div><br></div><div=
><br></div></div></div>
</blockquote></div>

--000000000000e7d49506151e3012--