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.
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.
Signed tags only help if you trust the package developer. I don't want
to have to trust anyone.
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.
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.
-- Tim Starling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
