Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:8636 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62905 invoked by uid 1010); 19 Mar 2004 23:52:03 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 62878 invoked from network); 19 Mar 2004 23:52:03 -0000 Received: from unknown (HELO asuka.nerv) (24.100.195.79) by pb1.pair.com with SMTP; 19 Mar 2004 23:52:03 -0000 Received: (qmail 22179 invoked from network); 19 Mar 2004 23:52:02 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 19 Mar 2004 23:52:02 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: internals@lists.php.net Date: Fri, 19 Mar 2004 18:52:08 -0500 User-Agent: KMail/1.6.1 References: <61700.66.158.132.127.1079718509.squirrel@www.funio.com> <200403191801.31596.ilia@prohost.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <200403191852.08922.ilia@prohost.org> Subject: Re: [PHP-DEV] new security related directive for php-4.3.4 From: ilia@prohost.org (Ilia Alshanetsky) On March 19, 2004 06:19 pm, Rasmus Lerdorf wrote: > This is also not the argument here. How many times have you heard me say > that this should not be PHP's problem? It is architecturally incorrect to > fix this problem in PHP and it can never be done correctly. However, PHP > is also the pragmatic solution to the web problem and until such a time > when someone else decides to actually fix this, we have to address it. > And I completely don't buy the "improving our hacks prevents development > of a real solution" argument. If we were talking about the same > developers working on both, or even if there was a clear way to solve the > actual problem that argument might have some weight, but it isn't the same > developers nor is there a straightforward way to solve this just looking > for someone to sit down and write the code. Once PHP begins (already did I suppose) implementing these hacks we'll just have more and more people convinced that this is a PHP issue and push for further hacks on top of the existing ones. Between adding these hacks and fixing various bugs resultant from these hacks or various bypasses of these 'security' measures much developer time (better spent elsewhere) is wasted. Before this discussion goes even further let me just summarize my position: -1 Ilia