Hi,
let's take this to a new thread so it'S not hidden in other discussions:
I do not think it is necessary for 5.3. It is an alpha release after
all and seriously, anyone who plans to move to 5.3.0 and still
relies on magic quotes gpc is likely to have more issues as well.Time to turn it off by default then?
Getting rid of magic_quotes would be really nice but has a very big
"BUT".
Many things (I won't call it "applications" or something...) out there
are accidentially more or less safe due to magic_quotes. Many of these
things were written by people with, at most, basic understanding of the
what they are doing and now are running at some random hosting company
on a $9.99/year (no idea what today's prices are)
When dropping magic_quotes the hosting company can do one of two things:
a) not update to 5.3 so we either have to maintain 5.2 for some time or
let them have problems
b) update to 5.3. Doing that means they break many of there customer's
code. Now they could add a default filter to add quotes again, what's
the win? Except that it will break magic_quotes-compatible code and
makes it harder to detect?
People won't fix the code - the code was "developed" by some web design
company 5 years ago and nobody touches the site anymore and there's no
maintenance contract between the design company and the site owner
anymore...
The only way I see for getting rid of magic_quotes is with a version
which will require people to touch the code anyways and with a big
"marketing campaign" so I think PHP 6 is a way better time for that even
so I'm really annoyed by it when doing stuff myself...
Comments and other views are welcome,
johannes
Hi,
let's take this to a new thread so it'S not hidden in other discussions:
I do not think it is necessary for 5.3. It is an alpha release after
all and seriously, anyone who plans to move to 5.3.0 and still
relies on magic quotes gpc is likely to have more issues as well.Time to turn it off by default then?
Getting rid of magic_quotes would be really nice but has a very big
"BUT".
Of course we can't remove it.
But I however find it very interesting that MQ_gpc is enabled by default.
-Hannes
Hi,
let's take this to a new thread so it'S not hidden in other discussions:
I do not think it is necessary for 5.3. It is an alpha release after
all and seriously, anyone who plans to move to 5.3.0 and still
relies on magic quotes gpc is likely to have more issues as well.Time to turn it off by default then?
Getting rid of magic_quotes would be really nice but has a very big
"BUT".Many things (I won't call it "applications" or something...) out there
are accidentially more or less safe due to magic_quotes. Many of these
things were written by people with, at most, basic understanding of the
what they are doing and now are running at some random hosting company
on a $9.99/year (no idea what today's prices are)When dropping magic_quotes the hosting company can do one of two things:
a) not update to 5.3 so we either have to maintain 5.2 for some time or
let them have problems
+1
I already discussed the possibility to maintain the 5.2 branch after
5.3-final (irc and some meetings) and I like to do it (in any case). I
do think it is something to do but only for critical bug fixes
(security or crash only).
We may say that it is the job of the distributors, but I'd to
disagree. It is critical for us to provide sources and binary releases
of a stable branch officially, even after a newer branch has been
released.
Cheers,
Pierre
When dropping magic_quotes the hosting company can do one of two things:
a) not update to 5.3 so we either have to maintain 5.2 for some time or
let them have problems+1
We cannot simply nuke a feature that was once upon a time sold as a
security feature, and is still enabled by default, just "out of the
blue".
I already discussed the possibility to maintain the 5.2 branch after
5.3-final (irc and some meetings) and I like to do it (in any case). I
do think it is something to do but only for critical bug fixes
(security or crash only).
Of course should we continue to do security releases for "previous
minor releases" until the "new one" is up to .2 or .3 at least.
We may say that it is the job of the distributors, but I'd to
disagree. It is critical for us to provide sources and binary releases
of a stable branch officially, even after a newer branch has been
released.
How are distributions supposed to keep up to date with security fixes
anyway? The only distro that has a chance is RHEL because they have an
"inside guy".
We really need to work on our relationship with other distros,
starting with marking security fixes as security fixes.
-Hannes
On Mon, Dec 8, 2008 at 16:57, Pierre Joye pierre.php@gmail.com
wrote:On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter
johannes@php.net wrote:When dropping magic_quotes the hosting company can do one of two
things:a) not update to 5.3 so we either have to maintain 5.2 for some
time or
let them have problems+1
We cannot simply nuke a feature that was once upon a time sold as a
security feature, and is still enabled by default, just "out of the
blue".
Agreed, going from on by default to removed just feels odd.
Regards,
Philip
On Mon, Dec 8, 2008 at 16:57, Pierre Joye pierre.php@gmail.com
wrote:On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter <johannes@php.
net> wrote:When dropping magic_quotes the hosting company can do one of two
things:a) not update to 5.3 so we either have to maintain 5.2 for some
time or
let them have problems+1
We cannot simply nuke a feature that was once upon a time sold as a
security feature, and is still enabled by default, just "out of the
blue".Agreed, going from on by default to removed just feels odd.
I'd disable it by default in 5.3 and lets start throwing a strict
error if the configuration enables it.
Scott
Hi Scott,
Agreed, going from on by default to removed just feels odd.
I'd disable it by default in 5.3 and lets start throwing a strict
error if the configuration enables it.
Why do we have E_DEPRECATED if we're not going to use it?
- Steph
Steph Fox wrote:
Hi Scott,
Agreed, going from on by default to removed just feels odd.
I'd disable it by default in 5.3 and lets start throwing a strict
error if the configuration enables it.Why do we have
E_DEPRECATEDif we're not going to use it?
That's the one I meant, no idea why I thought strict.
Scott
hi,
I'd disable it by default in 5.3 and lets start throwing a strict error if
the configuration enables it.
A fatal error could be more effective. And the message can make the
reason behind the error very clear.
By the way and for the record here, they (magic quotes, register
global and safe mode) are already removed in php6.
Cheers,
Pierre
Pierre Joye wrote:
hi,
I'd disable it by default in 5.3 and lets start throwing a strict error if
the configuration enables it.A fatal error could be more effective. And the message can make the
reason behind the error very clear.
If it's gone in php6 then imho it should be throwing a deprecated error
already.
By the way and for the record here, they (magic quotes, register
global and safe mode) are already removed in php6.Cheers,
Scott
Hi Pierre,
A fatal error could be more effective. And the message can make the
reason behind the error very clear.
It's a very big jump from 'enabled by default' to 'fatal error'. It will
break a lot of legacy code with no prior warning.
By the way and for the record here, they (magic quotes, register
global and safe mode) are already removed in php6.
All the more reason to disable them all by default and have them throw
E_DEPRECATED in 5.3.
- Steph
Cheers,
Pierre
Hannes Magnusson wrote:
[...]
We really need to work on our relationship with other distros,
starting with marking security fixes as security fixes.
Yes, please do mark them as such.
-Hannes
Cheers,
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
2008/12/8 Johannes Schlüter johannes@php.net:
Hi,
let's take this to a new thread so it'S not hidden in other discussions:
I do not think it is necessary for 5.3. It is an alpha release after
all and seriously, anyone who plans to move to 5.3.0 and still
relies on magic quotes gpc is likely to have more issues as well.Time to turn it off by default then?
Getting rid of magic_quotes would be really nice but has a very big
"BUT".Many things (I won't call it "applications" or something...) out there
are accidentially more or less safe due to magic_quotes. Many of these
things were written by people with, at most, basic understanding of the
what they are doing and now are running at some random hosting company
on a $9.99/year (no idea what today's prices are)When dropping magic_quotes the hosting company can do one of two things:
a) not update to 5.3 so we either have to maintain 5.2 for some time or
let them have problemsb) update to 5.3. Doing that means they break many of there customer's
code. Now they could add a default filter to add quotes again, what's
the win? Except that it will break magic_quotes-compatible code and
makes it harder to detect?People won't fix the code - the code was "developed" by some web design
company 5 years ago and nobody touches the site anymore and there's no
maintenance contract between the design company and the site owner
anymore...The only way I see for getting rid of magic_quotes is with a version
which will require people to touch the code anyways and with a big
"marketing campaign" so I think PHP 6 is a way better time for that even
so I'm really annoyed by it when doing stuff myself...Comments and other views are welcome,
johannes
I had a whole diatribe about past experience with upgrading accounting
and EPOS systems pre Y2K. I deleted it. In short those that paid
attention didn't have a problem.
Those that know about it will be dealing with it or have already dealt
with it. Those that don't know about it, won't know about it in V5.3,
V6.0, V7.0, 8,9,10, enterprise, free-to-all,
any-version-number-or-name-which-makes-you-stand-up-and-look. I hope
that the majority are in the first group.
As I understand it, you developers do NOT have a duty of care to stop
us upgrading without first reading the changelogs.
But I also understand it is pretty shitty to miss a 1 liner (magic
quotes removed) and find everything broken and then to be told
RTFM/RTFCL.
If this is in V6, then it I would have though that this would be
better received than in V5 release.
Richard.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hi,
But I also understand it is pretty shitty to miss a 1 liner (magic
quotes removed) and find everything broken and then to be told
RTFM/RTFCL.
There's a difference between this and other breaks: Most other BC breaks
change the behavior in a way you can easily spot, the magic_quotes issue
will only be spotted when actually testing for it - using the PHP app as
it is supposed will work like a charm. Only when adding " or ' you get
an SQL error ... which is a big security issue. (which again is
different from other BC breaks which just result in not working code)
I don't safe stuff relying on magic_quotes is safe but kicking it will
open up way more attack vectors... :-(
johannes
I don't safe stuff relying on magic_quotes is safe but kicking it will
open up way more attack vectors... :-(
In my opinion, this isn't about opening attack vectors (one hole is
all it takes, so they're probably already vulnerable), but removing
mqgpc without fair warning to end users could open up plenty of
failure situations when the data is "trusted" and the developers
didn't strip/escape the [magic] quotes properly:
$_GET['search'] = "O'Reilly";
$sql = "select * from books where publisher = '" . $_GET['search'] ."'";
The above was never "safe", but it "worked" in a trusted environment
with mqgpc on. Removing it would cause a SQL error.
Note: I'm not condoning the use of mqgpc; just saying that disabling
it abruptly has potential for a lot of unintended breakage.
S
Johannes Schlüter escribió:
I don't safe stuff relying on magic_quotes is safe but kicking it will
open up way more attack vectors... :-(
A false sense of security is worst than no security at all.
--
"We have art in order not to die of the truth" - Friedrich Nietzsche
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/
In my opinion a big change like droping something that was and still
used by many people are a "security measure", albeit a poor one is
something that can only be done in a major release.
Hi,
let's take this to a new thread so it'S not hidden in other
discussions:I do not think it is necessary for 5.3. It is an alpha release after
all and seriously, anyone who plans to move to 5.3.0 and still
relies on magic quotes gpc is likely to have more issues as well.Time to turn it off by default then?
Getting rid of magic_quotes would be really nice but has a very big
"BUT".Many things (I won't call it "applications" or something...) out there
are accidentially more or less safe due to magic_quotes. Many of these
things were written by people with, at most, basic understanding of
the
what they are doing and now are running at some random hosting company
on a $9.99/year (no idea what today's prices are)When dropping magic_quotes the hosting company can do one of two
things:a) not update to 5.3 so we either have to maintain 5.2 for some time
or
let them have problemsb) update to 5.3. Doing that means they break many of there customer's
code. Now they could add a default filter to add quotes again, what's
the win? Except that it will break magic_quotes-compatible code and
makes it harder to detect?People won't fix the code - the code was "developed" by some web
design
company 5 years ago and nobody touches the site anymore and there's no
maintenance contract between the design company and the site owner
anymore...The only way I see for getting rid of magic_quotes is with a version
which will require people to touch the code anyways and with a big
"marketing campaign" so I think PHP 6 is a way better time for that
even
so I'm really annoyed by it when doing stuff myself...Comments and other views are welcome,
johannes--
Ilia Alshanetsky
In my opinion a big change like droping something that was and still used by
many people are a "security measure", albeit a poor one is something that can
only be done in a major release.
I concur.
regards,
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
In my opinion a big change like droping something that was and still used by
many people are a "security measure", albeit a poor one is something that can
only be done in a major release.I concur.
Like I said, we simply cannot nuke it. But we can however turn it off
by default.
-Hannes
In my opinion a big change like droping something that was and still used by
many people are a "security measure", albeit a poor one is something that can
only be done in a major release.I concur.
Like I said, we simply cannot nuke it. But we can however turn it off
by default.
and add a deprecation notice.
Cheers,
Pierre
As much as I hate the feature, I am not certain that is a good idea in
a minor release.
In my opinion a big change like droping something that was and
still used by
many people are a "security measure", albeit a poor one is
something that can
only be done in a major release.I concur.
Like I said, we simply cannot nuke it. But we can however turn it off
by default.-Hannes
Ilia Alshanetsky
As much as I hate the feature, I am not certain that is a good idea in
a minor release.
"If not now, when?"
- Steph
6.0 iirc its already off by default in that branch.
As much as I hate the feature, I am not certain that is a good idea
in a minor release."If not now, when?"
- Steph
Ilia Alshanetsky
hi,
6.0 iirc its already off by default in that branch.
It is not off by default, it has been removed completely. I re
introduced the check function (returning always false) later.
Cheers,
Pierre
6.0 iirc its already off by default in that branch.
Ilia, it doesn't exist in that branch!
- Steph
Hi!
"If not now, when?"
Later?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
"If not now, when?"
Later?
Would you mind reading the thread first please? :)
The subject's a tad misleading at this stage.
- Steph
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Steph Fox wrote:
"If not now, when?"
Later?
Would you mind reading the thread first please? :)
The subject's a tad misleading at this stage.
I seem to recall the discussion on this was completed a couple of years
ago, but since PHP6 is still being pushed back people are forgetting
what was agreed and are now trying to extend the life of PHP5 ;)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hello,
I don't post here often, but I wanted to input my thoughts. For the
most part, I am a end user who developers PHP applications for mine
and others needs.
We can't just drop something so soon and expect others to catch up and
be able to operate with no problems at all. There is tons of
applications out there that still only develop using the latest stable
version of PHP and do not realize that development versions of PHP
will break their applications. Personally all my scripts work all the
way up to PHP 6, but I know others I do download and use won't even
operate in 5.3 as it is right now.
I would suggest adding the deprecated note on the magic quotes feature
for 5.3. Just leave it at that. So those developing scripts know the
feature is deprecated, as well provide documentation on php.net on
using alternative methods to magic quotes. While this means having to
maintain testing magic quotes in PHP threw 5.3, this will give people
enough time (years at that), to get rid of magic quotes.
- Jeremy