Andi Gutmans wrote:
Hi all,
In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump
Windows 98&ME support from this point onwards. We are sticking to old
Windows APIs because of this support which doesn't make much sense
considering that Microsoft has stopped supporting those
Andi Gutmans wrote:
>
> In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump
> Windows 98&ME support from this point onwards. We are sticking to old
> Windows APIs because of this support which doesn't make much sense
> considering that Microsoft has stopped supporting those
Hello Andi,
On 12/20/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Unless anyone disagrees with this, we'll go ahead with this.
We are waiting since months, go ahead :)
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump
Windows 98&ME support from this point onwards. We are sticking to old
Windows APIs because of this support which doesn't make much sense
considering that Microsoft has stopped supporting those platforms six months
At 19:33 20/12/2006, Tony Bibbs wrote:
As a casual observer of this thread, this was the explanation that
really clarified the prior posts for me.
To give credit where credit's due, it was Wietse's post, not mine!
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
Committed.
On Dec 19, 2006, at 6:36 PM, Matt Wilmas wrote:
Hi Andrei,
Yeah, I see the patch you committed also included the changes that
were made
since my reply yesterday... I've attached a patch that removes a few
lines
that aren't present in the non-Unicode version.
Matt
- Origi
Hi Internals
A colleague of mine is currently working on creating new test
cases to improve the coverage of the PHP test cases and whilst
attempting to
write new tests for the assert extension hit on a problem when
attempting to query the current setting of ASSERT_CALLBACK. using the
ass
As a casual observer of this thread, this was the explanation that
really clarified the prior posts for me.
I think having option 3 (enforcement mode) would be great, however, if
everybody is tripping up on mis-managing expectations then I'd suggest a
play on semantics by calling it something
On 12/20/06, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
Pierre wrote:
> I do not want the mode 3, for the reasons I explained earlier. I also
>>
>> Actually, I do. Especially if I had some legacy non-filtering
>> application which I wanted to secure. I would prefer to break it hard
>> and then ass
Pierre wrote:
> I do not want the mode 3, for the reasons I explained earlier. I also
>>
>> Actually, I do. Especially if I had some legacy non-filtering
>> application which I wanted to secure. I would prefer to break it hard
>> and then assemble the pieces in the correct way, rather than play
>>
I've been looking at the php tests and would like to be able to contribute more
tests for basic PHP functions to help increase the test coverage and prevent
regressions when code is changed. I don't know how granular the CVS access
controls are so am not sure what is possible. I've been working
Hello,
On 12/20/06, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> output to browser, output to system (console/whatever else), sql, xml,
> streams, etc... all of them require special attentions.
Hello, safe mode 2.0! :)
Seriously, I do not think tainting is made for that - and we will have a
At 17:35 19/12/2006, Wietse Venema wrote:
Zeev Suraski:
> My 2c on this piece is that tainting can be a nice helper tool to
> reduce the likelihood of security problems in your code. Nothing
> more and nothing less.
>
> I too fear the possibility of tainting becoming the new
> safe_mode. "Outso
On 12/20/2006 12:26 PM, Andy Wharmby wrote:
Hi Internals
I am still pretty new to PHP but having spent the last couple of
months reviewing the PHP code and
getting to know how PHP ticks I would be happy to volunteer some time
take a look at some of the
outstanding issues with the COM extens
Stanislav Malyshev wrote:
I disagree - you describe scenario where the user chooses to
insufficiently or wrongly sanitize the data, and since tainting can not
protect from it you say tainting is not useful. However, as I already
said, tainting is not supposed to do that. It's like blaming comp
So my conclusion at this point is, that very frequently taint will not
improve the security significantly because any given input will still be
usable in an unfiltered/incorrectly filtered way for at least one
context. As such it just adds code at the very core of php that provides
too little o
Wez Furlong wrote:
On 12/8/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
As far as finding a maintainer is concerned, we can check again with
Wez. If
he doesn't have time we should probably be able to find someone who
can look
into some of those bugs. Despite bugs, I've never had issues with it.
Hi,
I assume its not possible to implement this as a PECL extension. As an
extension it would make sense though even in this b&w approach as it
would then truly be an optional tool you can use like a debugger without
cluttering the core.
regards,
Lukas
--
PHP Internals - PHP Runtime Develop
Stanislav Malyshev wrote:
Then I see little need for having in PHP. All it means that developers
now need to write a untaint wrapper around all incoming input to shut
PHP annoyances up. I can guarantee you a tons and tons of code that
No, they need to use recommended ways to work with variabl
Then I see little need for having in PHP. All it means that developers
now need to write a untaint wrapper around all incoming input to shut
PHP annoyances up. I can guarantee you a tons and tons of code that
No, they need to use recommended ways to work with variables - like
filters and othe
20 matches
Mail list logo
