Hi,
let's take this to a new thread so it'S not hidden in other discussions:
On Mon, 2008-12-08 at 16:06 +0100, Hannes Magnusson wrote:
> > 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 q
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> let's take this to a new thread so it'S not hidden in other discussions:
>
> On Mon, 2008-12-08 at 16:06 +0100, Hannes Magnusson wrote:
>> > I do not think it is necessary for 5.3. It is an alpha release after
>>
2008/12/8 Johannes Schlüter <[EMAIL PROTECTED]>:
> Hi,
>
> let's take this to a new thread so it'S not hidden in other discussions:
>
> On Mon, 2008-12-08 at 16:06 +0100, Hannes Magnusson wrote:
>> > I do not think it is necessary for 5.3. It is an alpha release after
>> > all and seriously, anyone
On Mon, Dec 8, 2008 at 16:57, Pierre Joye <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter <[EMAIL PROTECTED]> 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 ti
Hi,
On Mon, 2008-12-08 at 16:03 +, Richard Quadling wrote:
> 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 be
Hello Pierre,
Monday, December 8, 2008, 4:57:17 PM, you wrote:
> On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> let's take this to a new thread so it'S not hidden in other discussions:
>>
>> On Mon, 2008-12-08 at 16:06 +0100, Hannes Magnusson wrote:
>>>
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
On 8 Dec 2008, at 08:18, Hannes Magnusson wrote:
On Mon, Dec 8, 2008 at 16:57, Pierre Joye <[EMAIL PROTECTED]>
wrote:
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter
<[EMAIL PROTECTED]> wrote:
When dropping magic_quotes the hosting company can do one of two
things:
a) not update to 5
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
On 8 Dec 2008, at 16:35, Philip Olson <[EMAIL PROTECTED]> wrote:
On 8 Dec 2008, at 08:18, Hannes Magnusson wrote:
On Mon, Dec 8, 2008 at 16:57, Pierre Joye <[EMAIL PROTECTED]>
wrote:
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter <[EMAIL PROTECTED]
net> wrote:
When dropping magic_quote
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
--
PHP Internals - PHP Runtime Development M
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_DEPRECATED if we're not going to use it?
That's the one I meant,
hi,
On Mon, Dec 8, 2008 at 5:53 PM, Scott MacVicar <[EMAIL PROTECTED]> wrote:
> 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 t
Pierre Joye wrote:
> hi,
>
> On Mon, Dec 8, 2008 at 5:53 PM, Scott MacVicar <[EMAIL PROTECTED]> wrote:
>
>> 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
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 quot
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.
On 8-Dec-08, at 10:47 AM, Johannes Schlüter wrote:
Hi,
let's take this to a new thread so it'S not h
On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
> 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://ti
On Mon, Dec 8, 2008 at 20:15, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
>
>> 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
On Mon, Dec 8, 2008 at 8:38 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 20:15, Derick Rethans <[EMAIL PROTECTED]> wrote:
>> On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
>>
>>> In my opinion a big change like droping something that was and still used by
>>> many people ar
As much as I hate the feature, I am not certain that is a good idea in
a minor release.
On 8-Dec-08, at 2:38 PM, Hannes Magnusson wrote:
On Mon, Dec 8, 2008 at 20:15, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
In my opinion a big change like dropi
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
6.0 iirc its already off by default in that branch.
On 8-Dec-08, at 3:12 PM, Steph Fox wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
hi,
On Mon, Dec 8, 2008 at 9:48 PM, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> 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
http://blog.thepi
6.0 iirc its already off by default in that branch.
Ilia, it doesn't *exist* in that branch!
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Ilia,
given our current development model I completely agree. Thus I would like
to change it as described earlier. I am convinced that only following the
even=stable & odd=dev/testing model allows for longer maintenanance cycles
and fast development at the same time.
marcus
Monday, Decem
How would that model relate to patch, minor, major release schemes we
have right now. What you are proposing works for linux, where there is
only one "branch" and they can effectively do the odd/even approach.
But, what would it mean for PHP and our current versioning schema?
On 8-Dec-08,
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 o
Hello Ilia,
we would stick to the rule of only adding to internal APIs in a minor
branch series. Using the pre x.y.0 for time to add, change and delete
functions. I'll write more in a separate thread.
marcus
Monday, December 8, 2008, 10:19:32 PM, you wrote:
> How would that model relate to pat
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
--
PHP I
29 matches
Mail list logo