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
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
anE_CORE_ERRORif 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--
+1 for removing it.
Tyrael
+1 for removing it in trunk
Pierrick
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
anE_CORE_ERRORif 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
Yeah,
+1 for remove!
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-----Original Message-----
From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of Kalle
Sommer Nielsen
Sent: Wednesday, November 17, 2010 5:09 PM
To: Internals
Subject: [PHP-DEV] Magic quotes in trunkGreetings
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_ERRORif 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--
To unsubscribe,
visit:
http://www.php.net/unsub.php
My opinion is to remove them completely.
Big +1 from me. It is time for the feature to go.
Olivier (iPhone)
Le 2010-11-17 à 11:08, Kalle Sommer Nielsen kalle@php.net a écrit :
Greetings
My personal vote here goes towards removing them entirely.
What are your inputs on this matter?
--
regards,Kalle Sommer Nielsen
kalle@php.net
+1 for removal,
magic quotes stopped being a 'good' thing to do back when I first learnt what echo did.
Web hosts etc have plenty of version numbers to catch up on/upgrade too before they get to this being a problem.
(well most anyway)
-----Original Message-----
From: kalle@php.net [mailto:kalle.php@gmail.com] On Behalf Of Kalle Sommer Nielsen
Sent: 17 November 2010 16:09
To: Internals
Subject: [PHP-DEV] Magic quotes in trunk
My personal vote here goes towards removing them entirely.
What are your inputs on this matter?
--
regards,
Kalle Sommer Nielsen
kalle@php.net
What are your inputs on this matter?
+1 for removing magic quotes completely from trunk. Kill it with fire.
Adam
What are your inputs on this matter?
+1 for removing magic quotes completely from trunk. Kill it with fire.
Adam
+infinity. Burn baby burn. (Hudson Ford reference intended...unless
that makes me too old.)
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
+1 for removal
+1 for removal
On Wed, Nov 17, 2010 at 10:50 PM, Stanley Sufficool ssufficool@gmail.comwrote:
+1 for removal
What are your inputs on this matter?
I'm struggling with this topic. We must do something, but it's important to understand that plenty of people unknowingly rely upon this security feature that's still enabled by default. Granted 5.3 does generate E_DEPRECATED errors when magical quotes are enabled, but is one minor PHP version of errors enough to go from on to gone?
So while those in the know (e.g., people who follow this list) find them annoying and wish they never existed, what are the implications? I'm still unsure how best to handle this situation but wanted to express these feelings now. Whatever the case, the education effort towards data filtering and sanitization requires a lot of improvement.
Regards,
Philip
What are your inputs on this matter?
I'm struggling with this topic. We must do something, but it's important to
understand that plenty of people unknowingly rely upon this security
feature that's still enabled by default. Granted 5.3 does generate
E_DEPRECATEDerrors when magical quotes are enabled, but is one minor PHP
version of errors enough to go from on to gone?So while those in the know (e.g., people who follow this list) find them
annoying and wish they never existed, what are the implications? I'm still
unsure how best to handle this situation but wanted to express these
feelings now. Whatever the case, the education effort towards data
filtering and sanitization requires a lot of improvement.Regards,
Philip
I won't miss magic quotes if they're removed, but I can see the argument for
saying "not quite yet". Off-by-default is absolutely necessary if they're
kept. (Dear god, you mean they aren't off by default already?)
--Larry Garfield
What are your inputs on this matter?
I'm struggling with this topic. We must do something, but it's important to
understand that plenty of people unknowingly rely upon this security
feature that's still enabled by default. Granted 5.3 does generate
E_DEPRECATEDerrors when magical quotes are enabled, but is one minor PHP
version of errors enough to go from on to gone?So while those in the know (e.g., people who follow this list) find them
annoying and wish they never existed, what are the implications? I'm still
unsure how best to handle this situation but wanted to express these
feelings now. Whatever the case, the education effort towards data
filtering and sanitization requires a lot of improvement.Regards,
PhilipI won't miss magic quotes if they're removed, but I can see the argument for
saying "not quite yet". Off-by-default is absolutely necessary if they're
kept. (Dear god, you mean they aren't off by default already?)--Larry Garfield
This is true. And in addition to the E_DEPRECATED error, it's worth mentioning that 5.3 includes two optional php.ini-* files (php.ini-production and php.ini-development) that disable magic quotes. But of course not everyone uses these, and "default" is how PHP behaves without a php.ini file. Older versions of PHP include php.ini-dist (On) and php.ini-recommended (Off).
Regards,
Philip
-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com]
Sent: Thursday, November 18, 2010 7:41 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Magic quotes in trunkWhat are your inputs on this matter?
I'm struggling with this topic. We must do something, but it's
important to understand that plenty of people unknowingly rely upon
this security feature that's still enabled by default. Granted 5.3
does generateE_DEPRECATEDerrors when magical quotes are enabled,
but
is one minor PHP version of errors enough to go from on to gone?So while those in the know (e.g., people who follow this list) find
them annoying and wish they never existed, what are the implications?
I'm still unsure how best to handle this situation but wanted to
express these feelings now. Whatever the case, the education effort
towards data filtering and sanitization requires a lot of improvement.Regards,
PhilipI won't miss magic quotes if they're removed, but I can see the argument for
saying "not quite yet". Off-by-default is absolutely necessary if they're kept.
(Dear god, you mean they aren't off by default already?)
The voice of reason...
As much as I'd like to see magic quotes burning in hell (had the option to kill them when they were small, but unfortunately didn't), I'm wondering whether the people +1'ing are thinking about the potential consequences to doing this, and if they're also volunteering to respond (nicely!!) to the endless complaints, flames, and just general "what happened???!!!" mailing list emails that may flood us when this happens. With 6.0, we talked about having prepend-scripts that emulate magic quotes available, since like it or not - there are probably billions of lines of code out there that rely on the existence of magic quotes.
I don't have a strong opinion on whether we should remove magic quotes altogether in 5.4 and provide emulation instructions, or just disable it by default as a first step.
Zeev
As much as I'd like to see magic quotes burning in hell (had the option to kill them when they were small, but unfortunately didn't), I'm wondering whether the people +1'ing are thinking about the potential consequences to doing this, and if they're also volunteering to respond (nicely!!) to the endless complaints, flames, and just general "what happened???!!!" mailing list emails that may flood us when this happens. With 6.0, we talked about having prepend-scripts that emulate magic quotes available, since like it or not - there are probably billions of lines of code out there that rely on the existence of magic quotes.
I already help support users on IRC — good support channels have been
recommending against the use of magic quotes for ages anyway.
Yes, killing magic quotes will likely increase the support workload
for a time, but I do think it's worth it because in the longer run
it'll force people to write better code. Having it deprecated in the
5.3 series seems like sufficient warning to me. At any rate, pulling
the trigger and removing it from trunk will help get the word out long
before 5.4 has a stable release.
I mean, I take the point about it seeming sudden from a userland
perspective, but I just think the pros (vastly) outweigh the cons
here.
Adam
Yes, killing magic quotes will likely increase the support workload
for a time,
I don't think it would increase support workload. Most people won't
notice.
What happens is that applications which are a bit secure now will
continue to run as before but become completely insecure as there,
unfortunately, are many users who don't know about the different issues.
Code like
mysql_query("SELECT id FROM table WHERE name = '".$_GET['name']."'");
is not too easy to exploit right now. As soon as m_q is gone it's
trivial to exploit. And people won't notice. And lots of such code
exists. Maybe not with internals subscribers, but there are enough
people who learned programming just last week using PHP and have the $1
hosting package ... and many of these things live "forever".
I think the default can only be changed in a change which breaks "a
lot".
To be clear: I am NOT saying that m_q is secure or safe. But dropping it
lowers he bar quite a lot.
johannes, who said this in multiple threads before ;-)
2010/11/18 Zeev Suraski zeev@zend.com:
The voice of reason...
As much as I'd like to see magic quotes burning in hell (had the option to kill them when they were small, but unfortunately didn't), I'm wondering whether the people +1'ing are thinking about the potential consequences to doing this, and if they're also volunteering to respond (nicely!!) to the endless complaints, flames, and just general "what happened???!!!" mailing list emails that may flood us when this happens. With 6.0, we talked about having prepend-scripts that emulate magic quotes available, since like it or not - there are probably billions of lines of code out there that rely on the existence of magic quotes.
I don't have a strong opinion on whether we should remove magic quotes altogether in 5.4 and provide emulation instructions, or just disable it by default as a first step.
I think we either should kill it or disable it now and remove it in
the next major version of PHP, be that 5.5 or 6.0. I don't think we
should provide emulation instructions, but rather some improved
chapters in the manual about what they are, how they work and how to
make sure applications are "protected" / compatible against them, so
even the basis PHP developer takes it into consideration.
Because even doing: $mysqli->query('SELECT * FROM developers WHERE
username = '' . $_GET['username'] . ''); is bad with or without
magic_quotes, theres a security issue non the less if people are
writing code like that.
I think we need to better educate our developers about these features,
and I wouldn't mind writing some manual pages regarding this we can
advertise with the release. Or at least find out how big a problem
with would be, because there are still many companies with legacy code
applications running an ancient version of PHP and never would upgrade
or similar reasons.
But all in all, I think it depends on us advertising it properly in
the manual, how to deal with it that is.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
I won't miss magic quotes if they're removed, but I can see the argument for
saying "not quite yet". Off-by-default is absolutely necessary if they're
kept. (Dear god, you mean they aren't off by default already?)
When opening my mouth on this list I often end up with my foot in it.
Hopefully this isn't one of them...
Disabling magic quotes by default leads to the same confusion and security
issues as removing them completely. But, we can remove magic quotes
completely if we add a fail safe mechanism. Here are two potential
options:
- Add taint support (http://news.php.net/php.internals/37209) and enable
it by default. This provides other security benefits, too.
or
- Error out if using CGI or web SAPI and one of the following is true:
a) php.ini does not contain "magic_quotes_gpc = Off"
b) php.ini contains "magic_quotes_runtime = On"
c) php.ini contains "magic_quotes_sybase = On"
d) php.ini does not exist
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi,
Disabling magic quotes by default leads to the same confusion and security
issues as removing them completely.
ACK
But, we can remove magic quotes
completely if we add a fail safe mechanism. Here are two potential
options:
- Add taint support (http://news.php.net/php.internals/37209) and enable
it by default. This provides other security benefits, too.
replace one magic which proved to be bad with another magic ...
or
- Error out if using CGI or web SAPI and one of the following is true:
a) php.ini does not contain "magic_quotes_gpc = Off"
b) php.ini contains "magic_quotes_runtime = On"
c) php.ini contains "magic_quotes_sybase = On"
d) php.ini does not exist
d) is no option.
johannes
Hi,
Disabling magic quotes by default leads to the same confusion and security
issues as removing them completely.ACK
But, we can remove magic quotes
completely if we add a fail safe mechanism. Here are two potential
options:
- Add taint support (http://news.php.net/php.internals/37209) and enable
it by default. This provides other security benefits, too.replace one magic which proved to be bad with another magic ...
Plus the performance hit of the taint patch is rather nasty.
-R
As I remember correctly - taint's are designed to be used while developing.
They can be used in production (and 4-5% performance hit for the
security isn't much until you run something really big), but mostly
people will test it out on dev and deploy on production without
taints.
Still, I'd like to see them implemented allready. Will be one big + for PHP :)
As I remember correctly - taint's are designed to be used while developing.
They can be used in production (and 4-5% performance hit for the
security isn't much until you run something really big), but mostly
people will test it out on dev and deploy on production without
taints.
Still, I'd like to see them implemented allready. Will be one big + for PHP :)
For people with proper development environments removing magic_quotes is
a great thing. They (hopefully) know better what they are doing. The
issue are users who have no idea what they are doing. So a
development-only feature won't help.
johannes
Hi Johannes:
- Error out if using CGI or web SAPI and one of the following is true:
a) php.ini does not contain "magic_quotes_gpc = Off"
b) php.ini contains "magic_quotes_runtime = On"
c) php.ini contains "magic_quotes_sybase = On"
d) php.ini does not existd) is no option.
Yeah, I hear you and figured there would be objection.
At the same time, for server administrators, isn't knowingly creating one
file with "magic_quotes_gpc = Off" in it a very low hurdle compared to
unknowingly getting pwn3d and then having to clean up that mess later?
If this isn't acceptable, let's come up with some other fail-safe options.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Fri, Nov 19, 2010 at 4:17 PM, Daniel Convissor <
danielc@analysisandsolutions.com> wrote:
Hi Johannes:
- Error out if using CGI or web SAPI and one of the following is true:
a) php.ini does not contain "magic_quotes_gpc = Off"
b) php.ini contains "magic_quotes_runtime = On"
c) php.ini contains "magic_quotes_sybase = On"
d) php.ini does not existd) is no option.
Yeah, I hear you and figured there would be objection.
At the same time, for server administrators, isn't knowingly creating one
file with "magic_quotes_gpc = Off" in it a very low hurdle compared to
unknowingly getting pwn3d and then having to clean up that mess later?If this isn't acceptable, let's come up with some other fail-safe options.
you can get pwn3d with magic_quotes_gpc = On also (through insecure usage
of register globals, or remote code inclusion/execution, xss/reflection and
sql injection also possible with enabled magic_quotes_gpc).
for example: http://www.exploit-db.com/papers/15446/
Tyrael
you can get pwn3d with magic_quotes_gpc = On
That goes without saying. None the less, it will be problematic for PHP
to disable/remove a "security" feature that some people rely on.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Fri, Nov 19, 2010 at 8:14 AM, Daniel Convissor
danielc@analysisandsolutions.com wrote:
you can get pwn3d with magic_quotes_gpc = On
That goes without saying. None the less, it will be problematic for PHP
to disable/remove a "security" feature that some people rely on.
Well then +1 for making the setting throw depreciated PHP startup
notifications when turned on with a link to suggested security
practices for SQL, exec(), passthru(), and other sensitive functions
benefiting from magic quotes.
Also throw an E_NOTICE depreciated for the magic_quotes_gpc() function
as well for those that check if this setting is on/off.
But please start the movement in the direction that this will be
removed in the future.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Fri, Nov 19, 2010 at 8:14 AM, Daniel Convissor
danielc@analysisandsolutions.com wrote:you can get pwn3d with magic_quotes_gpc = On
That goes without saying. None the less, it will be problematic for PHP
to disable/remove a "security" feature that some people rely on.Well then +1 for making the setting throw depreciated PHP startup
notifications when turned on with a link to suggested security
practices for SQL,exec(),passthru(), and other sensitive functions
benefiting from magic quotes.
Linking to a document sounds reasonable, but we already provide an E_DEPRECATED error when any magic quotes setting is enabled (as of 5.3.0), so the probable question here is if we should disable MQ by default (in 5.4) and remove it later (5.5 or 6.0), or simply remove it now. I lean towards disabling by default in 5.4, and removing in 6.0.
Also throw an
E_NOTICEdepreciated for the magic_quotes_gpc() function
as well for those that check if this setting is on/off.
Punishing people who write compatible code feels wrong, so get_magic_quotes_gpc() should never emit an error. Heck, this harmless function might even exist in PHP 7. My guess is most people simply run stripslashes() if On, rather than avoid superior escaping mechanisms.
But please start the movement in the direction that this will be
removed in the future.
I'm having a difficult time grasping the exact implications here, except that a default value change mostly affects people without php.ini files. I'm not sure who those people are, or how they may end up using PHP 5.4, but maybe a wiser old timer can predict this story. But for good measure:
What we have already done with magic_quotes_gpc:
(Note: sister magic_quotes_runtime has always defaulted to Off)
PHP 4, 5.0, 5.1, 5.2
- Default (On)
- php.ini-dist (On)
- php.ini-recommended (Off)
PHP 5.3
- Default (On)
- php.ini-development (Off)
- php.ini-production (Off)
-
E_DEPRECATEDerror when On
Distributions/vendors:
- I'm not sure which defaults they all use
We've recommended Off for a long time now (year ~2000) so should feel okay with whatever decision is made. But, our main focus is handling clueless code that magically works (sort of) thanks to magical quotes. Magic!
Regards,
Philip
On Fri, Nov 19, 2010 at 8:14 AM, Daniel Convissor
danielc@analysisandsolutions.com wrote:you can get pwn3d with magic_quotes_gpc = On
That goes without saying. None the less, it will be problematic for PHP
to disable/remove a "security" feature that some people rely on.Well then +1 for making the setting throw depreciated PHP startup
notifications when turned on with a link to suggested security
practices for SQL,exec(),passthru(), and other sensitive functions
benefiting from magic quotes.Linking to a document sounds reasonable, but we already provide an
E_DEPRECATEDerror when any magic quotes setting is enabled (as of 5.3.0), so the probable question here is if we should disable MQ by default (in 5.4) and remove it later (5.5 or 6.0), or simply remove it now. I lean towards disabling by default in 5.4, and removing in 6.0.Also throw an
E_NOTICEdepreciated for the magic_quotes_gpc() function
as well for those that check if this setting is on/off.Punishing people who write compatible code feels wrong, so
get_magic_quotes_gpc()should never emit an error. Heck, this harmless function might even exist in PHP 7. My guess is most people simply runstripslashes()if On, rather than avoid superior escaping mechanisms.
I retract my assertion that get_magic_quotes_gpc() throw anything. ;-)
But please start the movement in the direction that this will be
removed in the future.I'm having a difficult time grasping the exact implications here, except that a default value change mostly affects people without php.ini files. I'm not sure who those people are, or how they may end up using PHP 5.4, but maybe a wiser old timer can predict this story. But for good measure:
What we have already done with magic_quotes_gpc:
(Note: sister magic_quotes_runtime has always defaulted to Off)
PHP 4, 5.0, 5.1, 5.2
- Default (On)
- php.ini-dist (On)
- php.ini-recommended (Off)
PHP 5.3
- Default (On)
- php.ini-development (Off)
- php.ini-production (Off)
E_DEPRECATEDerror when OnDistributions/vendors:
- I'm not sure which defaults they all use
We've recommended Off for a long time now (year ~2000) so should feel okay with whatever decision is made. But, our main focus is handling clueless code that magically works (sort of) thanks to magical quotes. Magic!
FWIW, My SQL Server code doesn't magically work with this setting on,
I just get a bunch of crappy "quote\\\\\'s " values after
several iterations.
Regards,
Philip
Hi:
PHP 5.3
- Default (On)
- php.ini-development (Off)
- php.ini-production (Off)
E_DEPRECATEDerror when On
The deprecated message is only thrown if you set magic quotes to on in a
php.ini file. If you're runnning with no php.ini file, magic quotes gpc
is still on, but no message comes up. So there is no direct way PHP
itself tells such users/administrators that there's a problem or that the
feature is being deprecated. It seems unwise to just yank the rug out
from under these folks.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
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
anE_CORE_ERRORif 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
Certainly +1 for removal, but wasn't there some discussion a LONG
while ago about when this should be?
I would have thought that anything deprecated would best be removed at
the next major release. So that makes it gone for V6 - when ever that
may be.
Richard
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
+1 for removal.
The issue is that those ho still use the soft witch relies on
magic_quotes are usually kind of people witch are just buying the
Indian code stuff and running it (and it has tons of exploits on it's
own - even with magic_quotes). No, really, I haven't seen the
magic_quotes stuff in ages even in open source. Most of the things
that use it runs on 4.4.x and just unable to run on 5.x+ due to bad
coding and not following the trends.
There always will be people, who will whine about magic_quotes being
gone. Same as register_globals. BTW, will the register_globals will be
finally dropped too? ;)
Hi
2010/11/18 Arvids Godjuks arvids.godjuks@gmail.com:
There always will be people, who will whine about magic_quotes being
gone. Same as register_globals. BTW, will the register_globals will be
finally dropped too? ;)
I dropped a bunch of legacy features together with Pierrick during
this summer, so yes register_globals are gone along with safe_mode:
http://php.net/php6news
--
regards,
Kalle Sommer Nielsen
kalle@php.net
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
anE_CORE_ERRORif 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--
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
On Thu, Nov 18, 2010 at 11:41 AM, Patrick ALLAERT patrickallaert@php.netwrote:
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
anE_CORE_ERRORif 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--
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
--
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
2010/11/18 Ferenc Kovacs info@tyrael.hu:
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
(see my previous mail)
All of these so called legacy features (in my perspective) except
magic_quotes were removed:
http://php.net/php6news
and as Jani noted, its on by default if no php.ini file is used
(hardcoded into the binary to fallback to "On")
--
regards,
Kalle Sommer Nielsen
kalle@php.net
On Thu, Nov 18, 2010 at 11:51 AM, Kalle Sommer Nielsen kalle@php.netwrote:
2010/11/18 Ferenc Kovacs info@tyrael.hu:
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(see my previous mail)
All of these so called legacy features (in my perspective) except
magic_quotes were removed:
http://php.net/php6news
yeah, from the trunk, I know, I've just wanted to say, that we should either
drop the legacy stuff with the next version, or keep it, but I think thats a
bad idea, that we drop some of them.
if the only thing thats blocking the cleanup is the version number for the
next major release, then we should change that.
http://marc.info/?l=php-internals&m=123522403030163&w=2
Exactly. To summarize:
x.y.z to x.y.z+1: ABI and API must be 100% compatible
x.y.z to x.y+1.z: ABI can be broken (need a recompilation), API must
be 100% compatible
x.y.z to x+1.y.z: party time ;)
with the removal of the legacy features I think we can say, that we
break the API.
Tyrael
2010/11/18 Ferenc Kovacs info@tyrael.hu:
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
Indeed, I think that we can't decide on such change ignoring what will
be the next version number. Maybe we need a ROADMAP? :)
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.
AFAICT magic_quotes_gpc is still "On" in PHP_5_3 and trunk if you don't use any php.ini:
$ php -n --ri core | grep magic
magic_quotes_gpc => On => On
magic_quotes_runtime => Off => Off
magic_quotes_sybase => Off => Off
Or what did you mean? :)
--Jani
2010/11/18 Jani Taskinen jani.taskinen@iki.fi:
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.AFAICT magic_quotes_gpc is still "On" in PHP_5_3 and trunk if you don't use any php.ini:
$ php -n --ri core | grep magic
magic_quotes_gpc => On => On
magic_quotes_runtime => Off => Off
magic_quotes_sybase => Off => OffOr what did you mean? :)
--Jani
Jani, you are 100% right, I did not conceive that it was possible and
sane to change php.ini's default value without the internal fallback.
It makes me feel that it is therefore even more important to accept
such a change in a PHP greater than 5!
Patrick
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)?
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?
-----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 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
anE_CORE_ERRORif 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--
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
+1 Disabling magic quotes (off by default) and removing them in the next
major release.
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
On November-17-10 11:09 AM Kalle Sommer Nielsen wrote:
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
anE_CORE_ERRORif 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?
IMHO, removing magic_quotes should be done only in the next major version.
Far too many people are going to get bit on the behind by this type of
change in a minor version. I do agree it needs to crash and burn, but I
think it'll take millions of lines of code down with it (sadly).
To me, removing it and disabling it by default are practically speaking
the same thing. So the same applies -> next major version.
If by consensus the group should decide to go ahead anyway, I would suggest
a big fat notice with the release announcement and a prominent spot on the
front page of php.net (now?), and perhaps consider bumping the version
number
up 1 (to 5.5?) just to get people's attention. This is huge.
Best Regards,
Mike Robinson
+1 for removing it.
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
anE_CORE_ERRORif 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