Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62040
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANVTSm4pseLgp5RnD0Uh5aSvu3Zox6wwu65jDjikTeBXFyySDw@mail.gmail.com>
References: <CANVTSm4pseLgp5RnD0Uh5aSvu3Zox6wwu65jDjikTeBXFyySDw@mail.gmail.com>
Date: Sat, 4 Aug 2012 22:12:14 +0200
Message-ID: <CAH-PCH6WLj329chQHC6syTUh0vAmW3pUjnqXcHryi366+korHA@mail.gmail.com>
To: Yahav Gindi Bar <g.b.yahav@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf30684819b8cb3304c6764275
Subject: Re: [PHP-DEV] Integrate PECL into PHP
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf30684819b8cb3304c6764275
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar <g.b.yahav@gmail.com> wrote=
:

> Hi,
>
> After the last discussion I've started about runkit which some of you
> suggest to keep it in PECL - I thought about the extensions "problem" in
> PHP and wish to ask for your opinion.
>
> Many developers use shared hosting as PHP env which not allows them to
> install new extensions in PHP.
> In order to give users ability to use extensions, I'm suggesting that we'=
ll
> add some PECL related methods to the PHP core (with ini option to disable
> it, or create a PECL package) that allows users to install PECL packages
> through PHP code even in shared hosting env.
>
> We had dl() until it was deprecated, and even when we got it I guess that
> administrators disabled the dl() method because of security reasons.
> However, PECL got limited extensions which, as long as I know, does not p=
ut
> the server into security risks (maybe I've said something VERY STUPID rig=
ht
> now, so excuse me...)
>
> Idea example:
>
> <?php
>
> $extensionsList =3D pecl_get_available_extensions();
> if (! pecl_extension_installed('...') ) {
>     pecl_install_extension('...');
> }
>
> ?>
>
> What do you think?
>

hi

it is more complicated than that.
pecl is two thing, it is an addition/extension of the pear packaging
infrastructure and pecl is the pear channel hosted on http://pecl.php.net/
the pecl client depends on packages like make, autoconf, automake, php-dev,
etc. to be able to install a pecl package as the packages as hosted as
source code and compiled by the installation process.
it is true that there is an approval process for registering a new package
on pecl.php.net but the pecl extensions are maintained separately from the
php core, and their stability and the response to security issues are lower
than the one for php-src.
with your feature request, you are suggesting that php-src should include a
pear/pecl client which should be aware that only the packages from the
official php.net channels are allowed to be installed (else one can install
anything from anywhere), and you would still need to ask your hoster to
install the make, php-dev, etc. packages for this feature to work.
and if we would add this, from that point, any security issue in any pecl
package would be as serious problem as it was in the php-src.
of course the ISPs and the security minded sysadmins would ask for an
option to be able to disable this feature, which in most distribution would
be the default option.
so in the end, the users of the shared hosting providers would still not be
able to install C extensions on their own, but we would introduce a
potential attack vector to the core.
I think that it isn't something that we should pursue.
--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf30684819b8cb3304c6764275--