Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50339 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37612 invoked from network); 18 Nov 2010 10:50:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Nov 2010 10:50:25 -0000 Authentication-Results: pb1.pair.com header.from=james.butler@edigitalresearch.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=james.butler@edigitalresearch.com; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain edigitalresearch.com does not designate 217.154.180.62 as permitted sender) X-PHP-List-Original-Sender: james.butler@edigitalresearch.com X-Host-Fingerprint: 217.154.180.62 analysis.edigitalresearch.com Linux 2.6 Received: from [217.154.180.62] ([217.154.180.62:32990] helo=mail.edigitalresearch.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5D/17-32235-FE405EC4 for ; Thu, 18 Nov 2010 05:50:25 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.edigitalresearch.com (Postfix) with ESMTP id 034641C6564; Thu, 18 Nov 2010 10:50:20 +0000 (GMT) X-Virus-Scanned: amavisd-new at edigitalresearch.com Received: from mail.edigitalresearch.com ([127.0.0.1]) by localhost (mail.edigitalresearch.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfmUBQBYxA+H; Thu, 18 Nov 2010 10:50:19 +0000 (GMT) Received: from zarafa.localdomain (unknown [10.0.0.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.edigitalresearch.com (Postfix) with ESMTPS id 4D7501C6555; Thu, 18 Nov 2010 10:50:19 +0000 (GMT) Received: from zarafa.edigitalresearch.com (zarafa.edigitalresearch.com [10.0.0.20]) by zarafa.localdomain (Postfix) with SMTP id CA5351004A0; Thu, 18 Nov 2010 10:50:17 +0000 (GMT) To: =?windows-1252?Q?Patrick_ALLAERT?= , =?windows-1252?Q?Kalle_Sommer_Nielsen?= Cc: =?windows-1252?Q?Internals?= Date: Thu, 18 Nov 2010 10:50:17 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 6.40.2-22452 Thread-Index: AcuHDmOJuChAOJ/WTaKwuMxv3F2IeA== Message-ID: Subject: RE: [PHP-DEV] Magic quotes in trunk From: james.butler@edigitalresearch.com (=?windows-1252?Q?James_Butler?=) The only problem I can see with this is... do we wait for PHP6 as it seems to be becoming a bit of a Perl 6 (sorry for bringing this up)=3F I completely agree with it should only happen with major version change and most people won't see 5.x -> 5.y being a major change and therefore the end user expectation will be for things to generally to carry on working I'm not sure what the best answer is apart from jumping ahead with a PHP6, but is it really worth jumping the gun just for MQ's etc=3F -----Original Message----- From: patrickallaert@php.net [mailto:patrick.allaert@gmail.com] On Behalf Of Patrick ALLAERT Sent: 18 November 2010 10:41 To: Kalle Sommer Nielsen Cc: Internals Subject: Re: [PHP-DEV] Magic quotes in trunk 2010/11/17 Kalle Sommer Nielsen : > Greetings > > I wanted to raise this topic before we go Alpha with trunk, regarding > our beloved magic_quotes feature. There seems to be mixed opinions > regarding it so I thought I would take it up for discussion. > > We have advised people not to use magic_quotes, register_globals and > the like for years, and they were marked as deprecated in 5.3.0+ if > activated through their php.ini directives. Yet magic_quotes still is > set to "On" in 5.3.0. I think its worth we either remove the feature > or disable it in trunk as its a security related feature. Lets have a > look at what each of those options means: > > Removing magic_quotes): > Means we will remove the feature entirely in the source, we will throw > an E_CORE_ERROR if activated so people who have it enabled are forced > to disable it and make their applications work without magic_quotes. > This creates a minor issue for the hosts that simply disable it and > have their customers applications run without them which can create a > security risk for them, although it should be fairly limited. The > functions to check for magic_quotes_runtime should however stay for BC > to avoid applications that run on multiple versions of PHP from doing: > if(function_exists('...') && ...) > > Disabling them): > This will help to disable the spread of magic_quotes even more, and it > can safely be removed in the next major version of PHP. > > > My personal vote here goes towards removing them entirely. > > > What are your inputs on this matter=3F > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php I am all for removing it but... Disabling it by default is the first mandatory step, [done] in PHP 5.3, magic_quotes_gpc has been turned off by default at the same time as providing a -development and -production version of the php.ini file. However, such a change might be risky in the PHP5 series! Release the exact same thing as PHP 5.4 or PHP 6, there is a big difference in the user perception. * Is my PHP 5.x application compatible with PHP 6=3F * Chance is higher that they will take more care reading a PHP 5.3 -> PHP 6 Migration guide than a 5.3 -> 5.4. +1 to remove it in PHP > 5 Patrick --=20 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php