Everything

php

Retire distributions repo in favor of something more suitable

php.internals

Christoph Becker

5 years ago

Hi all,

the distributions repo[1] is huge (current ~ 26GiB), and it will grow
further over time; that causes issues when trying to check it out[2],
and frankly, I don't see why were having the tarballs in a VCS at all.

Wouldn't it be more suitable to make the tarballs available somewhere
else?  Since we're using Github anyway, an appropriate place could be
the tags, where it is already possible to add attachments.

From what I can tell, that would require some modifications to web-php
and web-qa, so that the proper download links would be available there,
but otherwise shouldn't be a big issue.

Thoughts?

Christoph

[1] <https://github.com/php/web-php-distributions>
[2]
<https://github.com/php/web-php/commit/78298f759b19a58b12ea20dde4f6be5b15a96ba2#commitcomment-50062830>

Ben Ramsey

5 years ago

> On Apr 27, 2021, at 09:41, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>
> Hi all,
>
> the distributions repo[1] is huge (current ~ 26GiB), and it will grow
> further over time; that causes issues when trying to check it out[2],
> and frankly, I don't see why were having the tarballs in a VCS at all.
>
> Wouldn't it be more suitable to make the tarballs available somewhere
> else?  Since we're using Github anyway, an appropriate place could be
> the tags, where it is already possible to add attachments.
>
> From what I can tell, that would require some modifications to web-php
> and web-qa, so that the proper download links would be available there,
> but otherwise shouldn't be a big issue.
>
> Thoughts?

Co-signed. I tried downloading it yesterday to add my key to the
keyring, but I canceled when I realized that my laptop might run out of
space. ;-)

Cheers,
Ben

Patrick ALLAERT

5 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2021-04-27 at 15:00, ben@benramsey.com wrote:

> > On Apr 27, 2021, at 09:41, Christoph M. Becker <cmbecker69@gmx.de>

wrote:

> >
> > Hi all,
> >
> > the distributions repo[1] is huge (current ~ 26GiB), and it will grow
> > further over time; that causes issues when trying to check it out[2],
> > and frankly, I don't see why were having the tarballs in a VCS at all.
> >
> > Wouldn't it be more suitable to make the tarballs available somewhere
> > else?  Since we're using Github anyway, an appropriate place could be
> > the tags, where it is already possible to add attachments.
> >
> > From what I can tell, that would require some modifications to web-php
> > and web-qa, so that the proper download links would be available there,
> > but otherwise shouldn't be a big issue.
> >
> > Thoughts?
>
>
> Co-signed. I tried downloading it yesterday to add my key to the
> keyring, but I canceled when I realized that my laptop might run out of
> space. ;-)
>
> Cheers,
> Ben

Huge +1 from my side.

Cheers,
Patrick
-----BEGIN PGP SIGNATURE-----
Version: FlowCrypt Email Encryption 8.0.4
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJgiCmXACEJEBmfnf72/7r9FiEE8faSI4+8FmblpczUGZ+d
/vb/uv0qSBAAmgZZx4a8x3dxgWGkeDLn+HDYw5gCVa4pGNfz+HLr5jwSP9c5
GTHqp3Ew3b7DmPta+nhvXT7oWfdaZFGk2zjkHYsc8ye4usdQvS8JO4epmwLx
v2TTChW1Pcwv6GzAAUH4iWI3kwe6lNU2qJxMxUtihk/aWrUerTVh+oWt0Gm+
bXtHyHqHaytvCyEaTJ52psUV7hT5G05xzsLhAq5pI2VZKZciJYK2UA1ysORp
30ithS42gG40TpxyZG/sJwd8XO+iikvVhazqqylvhnKW11ORyqnXWU5FskVL
VlRYv8qFaB5dsgne867U9rqxBXueG3HdTOpah5ydcSuVoxNcEtMkGQpp/Ptj
eEysRYRq1mYiqI9fRfj9JVYDVC4VyZ8pMtJ+9nnTMjywsZDEvfF+qKDjkEc5
UgmK4riSoEgzwwSMMpHQQ3+RFeAipEUV4IhOXnp0/toGFKVODTp9m1kMVsN9
nQym25gEFI2S+2KUTmSy7byKSYt1F8FL88GeenuV/iKl1HiigChgJ/Am7OFX
1TxnXtMtogCZVaOtLPELumA8ZFp6ONc6g5tl8rwOj5KZz0nbZD8p79tNBmPd
45g69y25Xcex20tt6uB64x7qUAcg/3XmZy59/KAoYUD816qqtlzURXFxKi9F
0+/SY9HoL2BMZVZsRzCJu9yKWd6E8r+28ZY=
=BYAn
-----END PGP SIGNATURE-----

Joe Watkins

5 years ago

Morning all,

I'd be very up for that ...

The "alternative workflow" in this document seems reasonable for us to use
(or modify for use):
https://wiki.debian.org/Creating%20signed%20GitHub%20releases

RE vendor lock-in: Any provider we may move to in the future is going to
have to be based on git,
and are going to have similar features to github with regard to providing
signatures.

If there's anything I can do to help, holla.

Cheers
Joe

On Tue, 27 Apr 2021 at 17:11, Patrick Allaert <patrick.allaert@gmail.com>
wrote:

Christoph Becker

5 years ago

On 28.04.2021 at 07:33, Joe Watkins wrote:

> RE vendor lock-in: Any provider we may move to in the future is going to
> have to be based on git,
> and are going to have similar features to github with regard to providing
> signatures.

Vendor lock-in is a good point, but I see no real issues with that; as
long as we keep <https://www.php.net/downloads.php> and
<http://qa.php.net/>, we could switch any time if need be.

Christoph

Nikita Popov

5 years ago

On Tue, Apr 27, 2021 at 4:41 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> Hi all,
>
> the distributions repo[1] is huge (current ~ 26GiB), and it will grow
> further over time; that causes issues when trying to check it out[2],
> and frankly, I don't see why were having the tarballs in a VCS at all.
>
> Wouldn't it be more suitable to make the tarballs available somewhere
> else?  Since we're using Github anyway, an appropriate place could be
> the tags, where it is already possible to add attachments.
>
> From what I can tell, that would require some modifications to web-php
> and web-qa, so that the proper download links would be available there,
> but otherwise shouldn't be a big issue.
>

One possible issue I see is that anyone with write access to the repo can
upload release artifacts (I think), and I'm not even sure if changes in
artifacts show up in the audit log.

Nikita

Joe Watkins

5 years ago

That's a good point.

I suppose the most we can do is prevent accidental committing of such
things.

Appears to be two "solutions" ...

We could distribute a pre-commit hook, which is somewhere between "not
bad", and "pretty awkward" if your git installation is old.
We could setup one of the unused boxes we have and leverage
api/actions/whatever and catch bad commits after they happen.

Neither of these are perfect solutions ... and I've never tried using hooks
with github, but with a quick read it seems people do it - it's another
paragraph in the git/vcs readme on the wiki.

Any more ideas ?

Cheers
Joe

On Wed, 28 Apr 2021 at 15:52, Nikita Popov <nikita.ppv@gmail.com> wrote:

Joe Watkins

5 years ago

Actually the detached signatures are not part of the normal commit process
(doesn't look like they'll be in logs either), but the tag that you need to
make the release archive is ...

So we'd really want restriction on creating tags, somehow ...

Possibly we could also emulate some of the protection that version files
used to have.

It's not so simple ...

Cheers
Joe

On Wed, 28 Apr 2021 at 16:18, Joe Watkins <krakjoe@gmail.com> wrote:

Nikita Popov

5 years ago

On Wed, Apr 28, 2021 at 4:18 PM Joe Watkins <krakjoe@gmail.com> wrote:

> That's a good point.
>
> I suppose the most we can do is prevent accidental committing of such
> things.
>
> Appears to be two "solutions" ...
>
> We could distribute a pre-commit hook, which is somewhere between "not
> bad", and "pretty awkward" if your git installation is old.
> We could setup one of the unused boxes we have and leverage
> api/actions/whatever and catch bad commits after they happen.
>
> Neither of these are perfect solutions ... and I've never tried using
> hooks with github, but with a quick read it seems people do it - it's
> another paragraph in the git/vcs readme on the wiki.
>
> Any more ideas ?
>
> Cheers
> Joe
>

I don't think the tags themselves are a problem -- for those at least we
have an audit trail in the form of our webhook integration, which sends out
emails for all tag creations/deletions, and by whom they were made. I'm not
even sure if our old karma setup had any special protection for tag
creation.

Having looked a bit closer now, it looks like the same would work for
release assets as well. There are webhooks for changes to releases, which
also list assets and who uploaded them. That should at least make us aware
of any changes.

Nikita

Christoph Becker

5 years ago

On 28.04.2021 at 16:47, Nikita Popov wrote:

> On Wed, Apr 28, 2021 at 4:18 PM Joe Watkins <krakjoe@gmail.com> wrote:
>
>> That's a good point.
>>
>> I suppose the most we can do is prevent accidental committing of such
>> things.
>>
>> Appears to be two "solutions" ...
>>
>> We could distribute a pre-commit hook, which is somewhere between "not
>> bad", and "pretty awkward" if your git installation is old.
>> We could setup one of the unused boxes we have and leverage
>> api/actions/whatever and catch bad commits after they happen.
>>
>> Neither of these are perfect solutions ... and I've never tried using
>> hooks with github, but with a quick read it seems people do it - it's
>> another paragraph in the git/vcs readme on the wiki.
>>
>> Any more ideas ?
>
> I don't think the tags themselves are a problem -- for those at least we
> have an audit trail in the form of our webhook integration, which sends out
> emails for all tag creations/deletions, and by whom they were made. I'm not
> even sure if our old karma setup had any special protection for tag
> creation.
>
> Having looked a bit closer now, it looks like the same would work for
> release assets as well. There are webhooks for changes to releases, which
> also list assets and who uploaded them. That should at least make us aware
> of any changes.

I think we can set up an approval workflow
(<https://dev.to/azure/using-environments-for-approval-workflows-with-github-actions-4962>).

Christoph