# Retire distributions repo in favor of something more suitable - Thread: https://externals.io/message/114198 - Original archive: https://news-web.php.net/php.internals/114198 - Started by Christoph M. Becker on 2021-04-27T14:41:15+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #114198 — Christoph M. Becker — 2021-04-27T14:41:15+00:00 URL: https://externals.io/message/114198#114198 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] [2] > > 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 --- ## #114201 — Patrick Allaert — 2021-04-27T15:11:21+00:00 URL: https://externals.io/message/114198#114201 · In reply to: #114199 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > > […] wrote: > > […] > > > 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 --- ## #114225 — Joe Watkins — 2021-04-28T05:33:16+00:00 URL: https://externals.io/message/114198#114225 · In reply to: #114201 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 wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > […] > wrote: > > […] > > 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----- > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #114227 — Christoph M. Becker — 2021-04-28T09:59:39+00:00 URL: https://externals.io/message/114198#114227 · In reply to: #114225 > 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 and , we could switch any time if need be. Christoph --- ## #114236 — Nikita Popov — 2021-04-28T13:51:51+00:00 URL: https://externals.io/message/114198#114236 · In reply to: #114198 On Tue, Apr 27, 2021 at 4:41 PM Christoph M. Becker 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 --- ## #114237 — Joe Watkins — 2021-04-28T14:18:12+00:00 URL: https://externals.io/message/114198#114237 · In reply to: #114236 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 > wrote: > > > […] > > 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 --- ## #114238 — Joe Watkins — 2021-04-28T14:23:13+00:00 URL: https://externals.io/message/114198#114238 · In reply to: #114237 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 > Joe > > > > > […] --- ## #114240 — Nikita Popov — 2021-04-28T14:47:52+00:00 URL: https://externals.io/message/114198#114240 · In reply to: #114237 > 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 > > > > […] --- ## #114241 — Christoph M. Becker — 2021-04-28T15:04:23+00:00 URL: https://externals.io/message/114198#114241 · In reply to: #114240 > > > > […] > > 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 (). Christoph