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
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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
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:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512On 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,
BenHuge +1 from my side.
Cheers,
Patrick
-----BEGIN PGP SIGNATURE-----
Version: FlowCrypt Email Encryption 8.0.4
Comment: Seamlessly send and receive encrypted emailwsFzBAEBCgAGBQJgiCmXACEJEBmfnf72/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-------
To unsubscribe, visit: https://www.php.net/unsub.php
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
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
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 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
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
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
JoeOn 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
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
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
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