Le 03/02/2012 09:34, David Soria Parra a écrit :
> Hi internals
>
> We like to announce the 7th Release Candidate of PHP 5.4.0.
> We fixed some critical bugs in the PHP 5.4.0 codebase. Therefore we
> release another RC. Hopefully the last one before the final.
Hi internals
This version comes wit
Hi Internals,
the Git migration is not finished yet and won't be finished for the
next weeks but we are constantly working on improvements.
There is now a new PHP Mailinglist called git-pu...@lists.php.net.
All pull requests requests created for the github.com/php user will
go to this mailinglis
On 03/02/12 21:44, Ángel González wrote:
> On 03/02/12 15:01, Gustavo Lopes wrote:
>> I've committed a different version that also forbids \0 (since, as
>> Stefan says, a NUL byte can result in the truncation of the rest of
>> the header) and that accepts a CRLF:
>>
>> http://svn.php.net/viewvc/php
On 03/02/12 23:00, Stas Malyshev wrote:
> Hi!
>
>> As it's a security patch and of small scope, I would consider it for
>> 5.4. Stas, David?
>
> Do we have unit tests for this code? The fix involves changes in header
> sending so it may have impact on lots of code. Changes like this can be
> dang
On Fri, Feb 3, 2012 at 10:37 PM, Reindl Harald wrote:
>
>
> Am 03.02.2012 21:44, schrieb Ángel González:
>>> If you or anyone else find any problem, please report a bug; otherwise
>>> I'll merge to 5.3 and 5.4 once 5.4 is out of code freeze.
>>>
>> As it's a security patch and of small scope, I wo
Hi,
>>> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997
>>
>> I'm sure we'd be more than happy to hear why it's broken and hear about
>> possible suggested fixes.
>
> The purpose of the code is to detect all occurences of \r or \n not followed
> by whitespac
Hi!
As it's a security patch and of small scope, I would consider it for
5.4. Stas, David?
Do we have unit tests for this code? The fix involves changes in header
sending so it may have impact on lots of code. Changes like this can be
dangerous. I'm thinking maybe we should wait with it unti
On Fri, Feb 3, 2012 at 10:37 PM, Reindl Harald wrote:
>
>
> Am 03.02.2012 21:44, schrieb Ángel González:
> >> If you or anyone else find any problem, please report a bug; otherwise
> >> I'll merge to 5.3 and 5.4 once 5.4 is out of code freeze.
> >>
> > As it's a security patch and of small scope,
Am 03.02.2012 21:44, schrieb Ángel González:
>> If you or anyone else find any problem, please report a bug; otherwise
>> I'll merge to 5.3 and 5.4 once 5.4 is out of code freeze.
>>
> As it's a security patch and of small scope, I would consider it for
> 5.4. Stas, David?
as it is SECURITY rele
On 03/02/12 15:01, Gustavo Lopes wrote:
> I've committed a different version that also forbids \0 (since, as
> Stefan says, a NUL byte can result in the truncation of the rest of
> the header) and that accepts a CRLF:
>
> http://svn.php.net/viewvc/php/php-src/trunk/main/SAPI.c?r1=323043&r2=323042&p
Okay, that's been removed from the patch. :)
From: John LeSueur [mailto:john.lesu...@gmail.com]
Sent: Friday, February 03, 2012 7:54 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [PATCH] Property Getters/Setters (v2.4) for review
Because Zend/zend_language_scanner.c is
Hi,
PHP fails to set the socket_last_error when stream_socket_server() times
out.
It is therefore impossible to tell if a timeout occurred or if the call
failed for some other reason.
Here is a simple piece of that should help understand this issue:
http://0.0.0.0:0>');
$client = stream_socket_
On Fri, 03 Feb 2012 15:13:56 +0100, John LeSueur
wrote:
I could be wrong, but doesn't:
(header_line[i+1] != ' ' && header_line[i+1] != '\t')
access an element past the end of the header_line array on the last
iteration of the for loop? shouldn't the for loop go until
header_line_len
- 1?
On Fri, Feb 3, 2012 at 7:01 AM, Gustavo Lopes wrote:
> On Fri, 03 Feb 2012 13:03:24 +0100, Gustavo Lopes
> wrote:
>
> On Fri, 03 Feb 2012 12:06:26 +0100, Stefan Esser <
>> stefan.es...@sektioneins.de> wrote:
>>
>> [snip]
>>> obviously inside PHP no one cares about reviewing security patches.
>>
On Fri, 03 Feb 2012 13:03:24 +0100, Gustavo Lopes
wrote:
On Fri, 03 Feb 2012 12:06:26 +0100, Stefan Esser
wrote:
[snip]
obviously inside PHP no one cares about reviewing security patches.
Perhaps then you'd want to comment on:
http://nebm.ist.utl.pt/~glopes/misc/bug60227.diff , whic
Because Zend/zend_language_scanner.c is a generated file, you could exclude
it from your diff, and end up with a much smaller patch. Smaller patches
are more appealing :)
On Fri, Feb 3, 2012 at 6:47 AM, Clint M Priest wrote:
> The property accessor functionality is done and is detailed here:
> h
The property accessor functionality is done and is detailed here:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Core Patch: http://www.clintpriest.com/patches/php-core/accessors/2.4.diff
The core patch encompasses the entire original RFC and the as-implemented
includes implementa
On Fri, 03 Feb 2012 12:06:26 +0100, Stefan Esser
wrote:
[snip]
obviously inside PHP no one cares about reviewing security patches.
Perhaps then you'd want to comment on:
http://nebm.ist.utl.pt/~glopes/misc/bug60227.diff , which addresses the
NUL byte issue, although now I'm thinking th
On Fri, 03 Feb 2012 12:06:26 +0100, Stefan Esser
wrote:
[snip]
Luckily it is not affecting everyone, because at least the Apache SAPI
will stop sending the header at the NUL byte, too.
However everybody running CGI/FastCGI will loose the protection with
this.
[snip]
Good point, and I
Hello,
I think current events show how important it is to make this case publicly
known.
On Dec 6th 2005 PHP got a partial protection against HTTP response splitting. A
security mitigation == Security Patch == important
The commit is here:
http://svn.php.net/viewvc/php/php-src/trunk/main/SAPI
Stefan Esser wrote:
I am not interested in pushing Suhosin into PHP mainline. Why in hell would I
want that. If Suhosin gets absorbed by PHP.net then I would have to start a new
project, because there are tons of mitigations I can think up that will be
implemented at some point in time and wil
On 02/03/2012 08:28 AM, Christoph Anton Mitterer wrote:
> The reasons why I've opened #657698 was just, because I though it could
> be possible for the PHP maintainers to reduce their burden, by just
> offering both, packages with suhosin and without.
> If there are bugs in the with suhosin version
Hello Pierre,
> Again, please tell me which part of Suhosin would make sense to have
> in the core? With technical explanation or details. Then we can begin
> a good discussion and maybe a RFC to get them in.
what part of "all of it and I am not going to try to convince you about this"
do you no
Hello Pierre,
> Please state the facts. I did add Debian and Ubuntu to the discussions
> on secur...@php.net. For all the issues you have reported yesterday
> (and I do the same for other). I do not know if Ondrej is on the
> security debian list, but that's up to them to deal with that.
Actually
hi Stefan,
On Fri, Feb 3, 2012 at 9:24 AM, Stefan Esser wrote:
> And it does not only look stupid to write such a mail at that moment it also
> shows how disconnected the Debian PHP maintainers are from what is happening
> around PHP.
> It also shows that the PHP devs seem to not like the Debi
hi Stefan,
On Fri, Feb 3, 2012 at 9:24 AM, Stefan Esser wrote:
> Hello Soenke,
>
>> I know it's hard because he personally attacks people and this doesn't
>> help at all, but deal with him. He really made PHP and the interwebs
>> more secure for the last decade.
>>
>> Do not respect him for how (
On Fri, Feb 3, 2012 at 09:24, Stefan Esser wrote:
> It also shows that the PHP devs seem to not like the Debian people, because
> otherwise they would have kept him in the loop. I know for a fact that Ubuntu
> and Redhat were informed.
Is that true that we don't have a Debian representative on
Hi internals
We like to announce the 7th Release Candidate of PHP 5.4.0.
We fixed some critical bugs in the PHP 5.4.0 codebase. Therefore we
release another RC. Hopefully the last one before the final.
You can download the packages from:
http://downloads.php.net/stas
The Windows team provid
Hey,
> How does it not look stupid for the "lead" maintainer of PHP in Debian* to
> write a "We do not need Suhosin, because I believe there will be no future
> Bugs in PHP" mail the very same day various PHP distributions have to put out
> updates because of a critical security bug that INFACT
Hello Soenke,
> I know it's hard because he personally attacks people and this doesn't
> help at all, but deal with him. He really made PHP and the interwebs
> more secure for the last decade.
>
> Do not respect him for how (bad) he's communicating things, respect him
> for what he coded. We are
Hey Florian,
> Now that's something I didn't read from Ondřej's mail, but delivering
> the packages with and without suhosin would, while being more work,
> certainly the most helpful way for users. Then again I'd gladly help if
> there's anything of this additional work that can be done.
people
31 matches
Mail list logo
