Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=uV0JJ8pCj3cbrfAlOrFmyq9wgsB1b835gneJ6UYL1nAUU7rzEeH8vfwWclRjZ04Dq/
         4HN7Zb2Tqbk29Ja7eracqApi2uyzfeIVuYuKlPbgCwNjtdb+hOMG4BkWG8tEzj3doSqX
         DbnPWUnDRY349Z6S0Zz5ydTlstnYkVrapYPWI=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <AANLkTimpE3UsPFp3o55dp_FnEr7m9aw74-xMqci72ZZE@mail.gmail.com>
References: <AANLkTin3-7w6wmFHvX+T+xoCF5HxSB=sSt4vYnkPW4y-@mail.gmail.com>
	<AANLkTimpE3UsPFp3o55dp_FnEr7m9aw74-xMqci72ZZE@mail.gmail.com>
Date: Thu, 18 Nov 2010 11:47:55 +0100
Message-ID: <AANLkTikJXPKGCGSXdnFsGVaNKDu6Nzv34iuj=hqmhpZE@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: Kalle Sommer Nielsen <kalle@php.net>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001636310843bec9670495518590
Subject: Re: [PHP-DEV] Magic quotes in trunk
From: info@tyrael.hu (Ferenc Kovacs)

--001636310843bec9670495518590
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 18, 2010 at 11:41 AM, Patrick ALLAERT <patrickallaert@php.net>wrote:

> 2010/11/17 Kalle Sommer Nielsen <kalle@php.net>:
> > 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?
> >
> > --
> > 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?
> * 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
by your logic, the same goes for register_globals and for the other
deprecated stuff, that we wanted to remove with the next major version.
maybe we should look this the other way around: if we agree that this things
have to go, and the only thing which blocks that is the version number, then
maybe we should ship something > 5

Tyrael

--001636310843bec9670495518590--