Hi!
what part of "all of it and I am not going to try to convince you
about this" do you not understand?
Well, here's the answer why Suhosin is not part of PHP.
With Suhosin existing I am free to implement as many security
mitigations I like and do not have to beg the PHP developers to
consi
On Sat, Feb 4, 2012 at 9:21 AM, Stas Malyshev wrote:
> One thing I do not understand though is how it is possible to say this and
> then complain about the lack of cooperation from PHP developers. When we
> explicitly invite you to participate, and you refuse - it's totally OK, you
> have no obli
Good morning,
> Well, here's the answer why Suhosin is not part of PHP.
>
>> With Suhosin existing I am free to implement as many security
>> mitigations I like and do not have to beg the PHP developers to
>> consider adding something.
>
> Some people call "begging" collaboration and consider it
Hi Pierre,
> And if security features in Suhosin is so critical, I also why its
> users rely on one single person for that, the bus factor is quite
> high.
everybody is free to join the Suhosin team.
People rely on me because they consider me the person knowing most about PHP
security.
And the
Hi!
A suhosin that is merged to PHP mainline will never provide the same
security as an external solution. This is not good enough for me.
That's your opinion and you completely entitled to it and I have
absolutely no issue about it. As I have no issue with your preferring to
keep Suhosin as
Hi!
This version comes with
- fileinfo 1.0.5-dev
- mysqlnd 5.0.10-dev
- sqlite3 0.7-dev
Thanks for the note, I think it makes sense to remove -dev from these
versions for the release. Any objections from the maintainers?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcr
Hello Stas,
> That's your opinion and you completely entitled to it and I have absolutely
> no issue about it. As I have no issue with your preferring to keep Suhosin as
> a separate project - it's your code, you decide what to do with it. What I
> have an issue with is understanding how, after
hi Stefan,
On Sat, Feb 4, 2012 at 9:41 AM, Stefan Esser wrote:
> But instead of accepting the gift, people like Pierre run around and tell
> everybody that people only have more problems due to Suhosin, that he is
> happy that it gets dropped, bla bla bla.
Yes, it causes more issues that it s
go ahead for fileinfo, maybe we should bump the version too as it does
not match anymore what has been done via pecl.
On Sat, Feb 4, 2012 at 10:02 AM, Stas Malyshev wrote:
> Hi!
>
>
>> This version comes with
>>
>> - fileinfo 1.0.5-dev
>> - mysqlnd 5.0.10-dev
>> - sqlite3 0.7-dev
>
>
> Thanks for
Hello Pierre,
>> This is ironic because Pierre's employer is Microsoft (excuse me if that is
>> not correct anymore).
>
> Again you are totally wrong. I work with them not for.
>
> And can you please once in this thread (or at all) stop your kiddish
> personal attack and finally bring technica
On Sat, Feb 4, 2012 at 10:25 AM, Stefan Esser wrote:
> Grow up Pierre.
here we go again... failed. next time
> See you do it again. You claim I believe EMET has been created because of
> Suhosin. I never said that. Although one of the lead developers of EMET
> compared it himself to it.
>
Hello Pierre,
>> See you do it again. You claim I believe EMET has been created because of
>> Suhosin. I never said that. Although one of the lead developers of EMET
>> compared it himself to it.
>> You know some features of Suhosin are already in PHP and the HTTP response
>> splitting drama sh
On Sat, Feb 4, 2012 at 11:32 AM, Pierre Joye wrote:
> On Sat, Feb 4, 2012 at 10:25 AM, Stefan Esser wrote:
>
>> Grow up Pierre.
>
> here we go again... failed. next time
>
>> See you do it again. You claim I believe EMET has been created because of
>> Suhosin. I never said that. Although one
Guys
sorry to barge in out of the blue, I recently signed up to the internals
list after many years as a PHP user (like many many people of course :) )
and after the recent non-too happy releases. I'm looking ever forward to
the next major PHP release and since I discovered the RFC's list I even
k
Hi!
This is bad. And there is no point arguing this fact.
Yes, this was bad. Agreed. It was a mistake. Mistakes happen. We fixed
it and hopefully learned from it.
These are all basic prinicples of security mitigations. Why is there
a need to write up RFC about these things. They are widely a
Hi!
Nevertheless PHP 5.3.9 introduced a vulnerability because PHP.net
cloned one of those "we see no need for any features" features.
Vulnerability was introduced because of the security fix for a specific
problem, that unfortunately was done incorrectly. If this feature were
requested befor
Pierre - please will you clarify if you are the
Pierre Joye
Software Engineer at Microsoft
Munich Area, Germany | Internet
Listed on LinkedIn
If not then at least it will explain why there is confusion over your connection
with Microsoft!
--
Lester Caine - G8HFL
-
Hi,
>> This is bad. And there is no point arguing this fact.
>
> Yes, this was bad. Agreed. It was a mistake. Mistakes happen. We fixed
> it and hopefully learned from it.
Yes mistakes do happen to everyone and we all hope to learn from them.
And some of us like to buy insurances so that there i
Hello,
> I only say a few words and then i will be silent
> I tend to agree with Linus on this one "Security people are insane"
Yes and the security community thinks that Linus is insane for his view on
security topics.
> Not words : write RFC(docs),patches with sane techincal disscussions
> or
On 04.02.2012 11:10, Lester Caine wrote:
> If not then at least it will explain why there is confusion over your
> connection with Microsoft!
I don't see how this belongs on internals, why don't you go write him a
mail in private?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
On Sat, Feb 4, 2012 at 12:06 AM, Ángel González wrote:
> I've gone ahead and written code for that feature. Comments welcome.
If I understand it correctly your code only allows \r\n[ \t] style
line continuations, whereas catahracts previous version allowed
(?>\r\n|\r|\n)[ \t]. Is that intentional
On Sat, 04 Feb 2012 00:06:45 +0100, Ángel González wrote:
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
On Fri, 03 Feb 2012 14:00:11 -0800, 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 d
On Sat, Feb 4, 2012 at 10:46 AM, Stefan Esser wrote:
> These are all basic prinicples of security mitigations. Why is there a need
> to write up RFC about these things. They are widely accepted by other
> software vendors/products.
Why do you need a RFC to propose something to the W3C, or pyth
Pierre,
> Why do you need a RFC to propose something to the W3C, or python? Even
> if it is widely adopted already. No need to answer, that's rather
> obvious.
you still fail to realize that I don't want to propose (anything) to you.
If you love writing RFCs then write some.
I am perfectly satis
On Sat, Feb 4, 2012 at 3:20 PM, Stefan Esser wrote:
> Pierre,
>
>> Why do you need a RFC to propose something to the W3C, or python? Even
>> if it is widely adopted already. No need to answer, that's rather
>> obvious.
>
> you still fail to realize that I don't want to propose (anything) to you.
>
Pierre,
I think we all know that 90% of your emails consist of twisting other people's
words in the hope to make them look bad
and redirect from the technical content.
Every time in this threat you replied to me, you were not adressing the
technical issue but taking some sentences and
twisting
Gustavo Lopes wrote:
> On Sat, 04 Feb 2012 00:06:45 +0100, Ángel González wrote:
>> I've gone ahead and written code for that feature. Comments welcome.
>
> The comparison has a problem: if char is signed (the most common
> scenario), you'll be making a signed comparison, so any character over
> 0x
On Sat, 04 Feb 2012 16:35:04 +0100, Ángel González wrote:
Gustavo Lopes wrote:
On Sat, 04 Feb 2012 00:06:45 +0100, Ángel González wrote:
I've gone ahead and written code for that feature. Comments
welcome.
The comparison has a problem: if char is signed (the most common
scenario), you'll be m
On Sat, 4 Feb 2012 10:25:21 +0100, Stefan Esser wrote:
See you do it again. You claim I believe EMET has been created
because of Suhosin. I never said that. Although one of the lead
developers of EMET compared it himself to it.
You know some features of Suhosin are already in PHP and the HTTP
res
A couple of quick comments...
Why can't the read-only and write-only keywords be implicit instead of
explicit? I've never seen another language where you have to explicitly
indicate what you're doing. At best, it acts an extra fail-safe to prevent
making errors - at worst, it just means more redun
OK, All the mud slinging is getting really silly (on *both* sides). There's no
need to denigrate others because you don't agree with them. There's no point in
arguing about who isn't a team player or who works for which evil multinational
corporation. Nobody is attacking anybody else by suggesti
Hi John,
Ondřej (One of the Debian PHP maintainers) listed 5 or 6 reasons in the
initial email in this thread.
Honestly, I can't think of a good reason for Debian or anyone else to
include 3rd party patches, whatever the patches purpose, in the default PHP
packages.
I would argue that, if peopl
+1
Not certain about a better solution but there are other methods of encrypting
and decrypting session data. In a recent project I have been tasked with
implementing a pdo stored procedure using mysql's aes functionality works well
with or without the patch. In a lot of ways I think that is th
-Original Message-
From: Rasmus Schultz [mailto:ras...@mindplay.dk]
Sent: Saturday, February 04, 2012 10:01 AM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 - Issue 2549
> Why can't the read-only and write-only keywords be implicit instead o
Hi,
Am 04.02.2012 19:13, schrieb Clint M Priest:
-Original Message-
From: Rasmus Schultz [mailto:ras...@mindplay.dk]
Sent: Saturday, February 04, 2012 10:01 AM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 - Issue 2549
Why can't the read-
Can I get access to update the status of bugs? I've gone through a few recent
ones and tested, some are bogus and I'm just adding comments but can close them
if I had access.
https://bugs.php.net/bug.php?id=60940
For example.
On Sat, Feb 4, 2012 at 7:00 PM, Clint M Priest wrote:
> Can I get access to update the status of bugs? I've gone through a few
> recent ones and tested, some are bogus and I'm just adding comments but can
> close them if I had access.
>
> https://bugs.php.net/bug.php?id=60940
>
> For example.
>
I guess my thought behind it was that __set() is supposed to be called whenever
writing data to inaccessible properties, I sought not to change the default
behavior of __set(). In the case of adding a read-only keyword was that it was
explicitly stating that the property cannot be written to in
https://bugs.php.net/bug.php?id=60833 seems like a change that nobody should
have a problem with and has a patch file attached, can someone commit this and
close the request?
Excerpts from Kiall Mac Innes's message of Sat Feb 04 09:34:44 -0800 2012:
> Hi John,
>
> Ondřej (One of the Debian PHP maintainers) listed 5 or 6 reasons in the
> initial email in this thread.
>
> Honestly, I can't think of a good reason for Debian or anyone else to
> include 3rd party patches,
I'm just looking into my annual dedicated server update since it's the only way
to get the current contract prices, and I find that ! and 1 are still
advertising support for PHP6 Beta :) I wonder how many more ISP's are keeping up
with them ...
--
Lester Caine - G8HFL
-
On Sat, Feb 4, 2012 at 1:13 PM, Clint M Priest wrote:
> The read-only and write-only keywords act a little differently. Without
> them, attempting a set on an accessor without a setter defined will cause
> __set() to be called whereas with the read-only it will produce an error.
> The inverse i
Could someone review and include?
https://bugs.php.net/bug.php?id=60978
-Clint
Yes, *something* has to be able to access the backing field to
implement such things, but as long as the class itself and its
subclasses can do so (protected) it seems like a feature not to have
the property outright public so the getters and setters don't get
ignored by the people who should be us
Hey.
So what's the result of this discussion now?!
^^
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Hi Clint,
On Sat, Feb 04, 2012 at 11:20:24AM -0800, Clint Byrum wrote:
> I think a more interesting discussion than the current one of "who
> plays nice with whom" and "why I don't like your processes", is whether
> anyone other than Stefan would be willing to champion RFCs for all of
> the Suhosi
47 matches
Mail list logo
