On Wed, 6 Dec 2023, Tim Starling wrote: > On 6/12/23 00:45, Derick Rethans wrote: > > The code is old, and hard to maintain. And the database is full of > > mojibake. It is also an outdated method of installing things, > > especially because userland code is so much easier to handle through > > Composer. > > Thanks for working on this. > > I would say that one of the reasons userland code is easier is because > composer packages are local and unprivileged, whereas extensions are > global and are typically require root to install. That problem is not > going to go away. For community-supplied packages we're mostly using > Ondrej Sury's Debian packages. For our own packages (LuaSandbox, > Excimer) we're building debs from git tags without reference to PECL. > So PECL for us is part of the release procedure just as a courtesy to > the downstream community.
>From what I can see, once you drop a "new-pecl.json" file (or whatever we'll end up calling it) into the repo at https://github.com/wikimedia/mediawiki-php-luasandbox it should automatically become compatible with the new PECL. You shouldn't have to deal with making actual packages and uploading them to the PECL website. I'm going to hope that that is an improvement for you? > In terms of security, there should be no way to get root by uploading > a malicious PECL package. With debs, I'm not sure if that separation > is rock-solid, but at least it exists aspirationally. During build, we > run code from the package as non-root. During installation, as root we > install generated files into locations which hopefully won't be > executed as root. To achieve this separation with PECL, there would > need to be some sort of system-aware privilege separation inside the > PECL installer. At least it should fork and drop root privileges. Yes, that is a good recommendation, and something that should definitely go into the design document. > Signed tags only help if you trust the package developer. I don't want > to have to trust anyone. That's true. I think signatures make more sense when a package is authored by a known organisation, such as wikimedia or MongoDB. Where the signatures therefore include these organisation's domain names. > The PHP version dependency is a tricky part of the spec. When we make > a release, we have no way to know how forwards-compatible it is. At > some point, a PHP core change will break the extension. The proposed > structure suggests that we would have to release a new version of the > extension just to say that it's broken. Then later when we make a fix, > we would release again with that information. I don't think you'll have to make a new *release*, as I was hoping to access the meta data file in the main/master branch. I solve this for Xdebug by always setting a hard upper limit. Better safe than sorry. > My motivation to maintain a historical list of supported version > ranges is very limited. I just want to declare, for the code I'm > actually releasing, the earliest supported PHP version and maybe the > latest confirmed PHP version. > > Have you considered keeping the support matrix in the registry > database, instead of in pecl.json? Then it can be updated with new > build/test information after release. Yeah, I understand. And I feel the same. But if there is no registry (a goal), then there is no way to find out which of your extension version support a specific PHP version, without checking every tag in your repository. That's not going to be fast. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
