Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53132 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73852 invoked from network); 7 Jun 2011 12:45:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Jun 2011 12:45:15 -0000 Authentication-Results: pb1.pair.com header.from=davidkmuir@gmail.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=davidkmuir@gmail.com; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain gmail.com does not designate 208.113.200.5 as permitted sender) X-PHP-List-Original-Sender: davidkmuir@gmail.com X-Host-Fingerprint: 208.113.200.5 caibbdcaaaaf.dreamhost.com Windows 98 (1) Received: from [208.113.200.5] ([208.113.200.5:38867] helo=homiemail-a57.g.dreamhost.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EE/38-30784-A5D1EED4 for ; Tue, 07 Jun 2011 08:45:15 -0400 Received: from homiemail-a57.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTP id CEC93208058 for ; Tue, 7 Jun 2011 05:45:01 -0700 (PDT) Received: from [192.168.3.3] (softbank221040106178.bbtec.net [221.40.106.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: david@thefourstooges.com) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTPSA id 6307C208049 for ; Tue, 7 Jun 2011 05:45:01 -0700 (PDT) Message-ID: <4DEE1D47.8060209@gmail.com> Date: Tue, 07 Jun 2011 21:44:55 +0900 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: internals@lists.php.net References: <8757232E56758B42B2EE4F9D2CA019C901499F97@US-EX2.zend.net> <97.45.23189.8060DED4@pb1.pair.com> <4DED5F9B.7060101@thelounge.net> <4DEDC9F5.3030403@thelounge.net> <4DEDF049.7050504@gmail.com> <4DEDF216.6070308@thelounge.net> In-Reply-To: <4DEDF216.6070308@thelounge.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Bundling "modern" extensions From: davidkmuir@gmail.com (David Muir) On 07/06/11 18:40, Reindl Harald wrote: > > Am 07.06.2011 11:32, schrieb David Muir: >> On 07/06/11 15:49, Reindl Harald wrote: >>> Am 07.06.2011 04:42, schrieb Martin Scotta: >>>> On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote: >>>> >>>>> Am 06.06.2011 23:40, schrieb Martin Scotta: >>>>> >>>>>> It'd be very nice if some extension could be enabled just by dropping the >>>>>> "extension file" on the path. >>>>>> So developers can check what they have using phpinfo, and then upload the >>>>>> needed extension using ftp. Is it possible? >>>>> if a "developer" only would try such idiotic action >>>>> he would lost his accounts forever and get fired from >>>>> one day to the next! >>>>> >>>>> WTF how can anybody have the idea that it would be a good >>>>> idea to let non-sysadmins uplod and execute binaries on a >>>>> server? >>>>> >>>>> >>>> Thanks you for all yours responses. >>>> Now it's clear what the issue is... the usage of compiled "libraries". >>>> >>>> We need some middleware between the core and PHP. >>>> That way extensions could be written in PHP, compiled and distributed in >>>> some "library" format. >>>> Library users just add them into their path, include them, and use the >>>> classes/functions as usual. >>>> >>>> - No OS dependence >>>> - minimum dependence with core version >>>> - size of core will reduce drastically >>>> - faster runtime, include only what libs you use, as you need them >>> what are you speaking about and since how long you are working >>> with PHP that you never heard about PEAR, ZendFramework....? >>> >> And you should know that PEAR and ZF are user-land libraries, not >> compiled libraries. > i know that > >> I think Martin is wishing for is the PHP Native Interface: >> https://wiki.php.net/rfc/php_native_interface > where is the real difference to a userland-library as PEAR > and the thousand other which exists and will we ever see > a solution for extensions wich is SECURE? > > there is a reason for example to disallow many functions > on a webserver - so every API has to make sure they > can not be bypassed > > "because we can" is no valid reason for everything because > we can install binary extension as they exist now and > if you can not you are missing the permissions for some > good reasons > So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? Python has ctypes. How did it solve the security problems? What exactly are the security issues? I'm really trying to figure out where you're coming from. Cheers, David