Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121935
Message-ID: <c6af7028-a731-4087-8245-40e543d05eb8@wikimedia.org>
Date: Wed, 6 Dec 2023 13:05:09 +1100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Derick Rethans <derick@php.net>,
 PHP Developers Mailing List <internals@lists.php.net>
References: <8d4bcca5-a2ce-5ee1-1aed-02076539433a@php.net>
In-Reply-To: <8d4bcca5-a2ce-5ee1-1aed-02076539433a@php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New "PECL"
From: tstarling@wikimedia.org (Tim Starling)

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