Crossposting to php-internals too since those are the guys who receive
the bugreports...
Debian unstable packages has recently disabled suhosin patch by
default (it is still kept as optional part which could be enabled at
compile time).
I am trying to summarize the reasons why I have decided to d
Working on the pecl website with Pierre Joye
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Ondřej,
> My personal feeling is that most people see suhosin as "this is about
> security, thus it must be good". This combined with bad PHP security
> history makes everybody feel insecure when suhosin was removed, but
> the real question is if the suhosin is still really helping with PHP
Hi Stefan,
On Thu, Feb 2, 2012 at 2:31 PM, Stefan Esser wrote:
> Hello Ondřej,
>
>> My personal feeling is that most people see suhosin as "this is about
>> security, thus it must be good". This combined with bad PHP security
>> history makes everybody feel insecure when suhosin was removed, but
Am 02.02.2012 14:38, schrieb Pierre Joye:
> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
> will have bugs. This is not really hot news. That does not affect this
> discussion.
>
> I, for one, like the idea to finally see distros droping Suhosin and
> focus on making PHP it
Hello Pierre,
> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
> will have bugs. This is not really hot news. That does not affect this
> discussion.
I know that for many years you have not understood the idea behind Suhosin, the
concept of exploit mitigations.
The only r
Ohh btw…
> I have walked the bug list for 5.3 mentioning suhosin[2] to actually
> at least partially support what I have just said. I have found few
> bugs where suhosin was causing a problems ([3],[4]) and a handful of
> bugs with "have suhosin, cannot help". I know this isn't (and can't
> be) a
Hi,
RC7 is already tagged but misses
http://svn.php.net/viewvc?view=revision&revision=323013 for earlier
today.
Guessing we try to avoid another RC, shouldn't we re-tag to include this
fix? It might delay the upcoming release tomorrow of RC7, but might help
to have a better final version based on
hi Stefan,
On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser wrote:
> Hello Pierre,
>
>> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
>> will have bugs. This is not really hot news. That does not affect this
>> discussion.
>
> I know that for many years you have not understood
On Thu, Feb 2, 2012 at 4:49 PM, Pierre Joye wrote:
> hi Stefan,
>
> On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser wrote:
> > Hello Pierre,
> >
> >> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
> >> will have bugs. This is not really hot news. That does not affect this
> >
Hello Pierre,
> For one, some were not not ported but features were implemented, with
> the support of their original authors. They are not related to
> Suhosin, like the Blowfish support, which I ported to php with the
> help of Solar Designer. Suhosin uses the same implementation.
Sorry it make
On Thu, Feb 2, 2012 at 5:10 PM, Stefan Esser wrote:
> Hello Pierre,
>
>> For one, some were not not ported but features were implemented, with
>> the support of their original authors. They are not related to
>> Suhosin, like the Blowfish support, which I ported to php with the
>> help of Solar De
On Thu, 2 Feb 2012, Stefan Esser wrote:
> Sorry it makes no difference if a feature was introduced into PHP by
> taking code from Suhosin or from someone else. Fact is the feature
> existed before in Suhosin.
>
> * GLOBALS overwrite protection
> * max_file_uploads
> * max_input_vars
> * crypt()
Hello Derick,
>> * and most probably many more that I do not know from the top of my
>> head (this are already 9 features and Suhosin/HPHP exists since 2004 =
>> 8 years).
>
> Lots of stuff in PHP was also "stolen" from Xdebug, but I am not whining
> about that as the goal is (and has always
Hello Pierre,
> This is exactly where you should help php directly instead of doing
> what you do now to defend your patch. In the long run (or maybe even
> mid term), the Suhosin patch will disappear.
I seriously doubt that. The PHP developers will never ever merge all features
into the PHP co
Hi!
yes, but suhosin-extension and hardening patch exists since many years
the question from a normal user:
why are these things not included in the core?
Because some of these things slow down the code and thus may not be
beneficial to the most users.
especially the option to disable fun
hi Stefan,
You do not want that to happen, that's different than we, as a
project, not willing to see what could be done and help you or anyone
to get that done. The RFC process also makes that possible in a very
easy and open way.
On Thu, Feb 2, 2012 at 5:40 PM, Stefan Esser wrote:
> Hello Pier
Am 02.02.2012 18:37, schrieb Stas Malyshev:
>> yes, but suhosin-extension and hardening patch exists since many years
>>
>> the question from a normal user:
>> why are these things not included in the core?
>
> Because some of these things slow down the code
we are using suhosin patch and exte
Hi!
I know that for many years you have not understood the idea behind
Suhosin, the concept of exploit mitigations.
I think we have a difference of approaches here, and it is well known.
There's more or less a consensus among PHP dev that to introduce a
feature, especially with high user perfo
Hi!
with many hundret active sessions was not a
single performance problem
I'm not sure I understand what you are talking about here. Performance
is a scale, not a trigger. If you lose 10% (totally invented number as
an example) that doesn't mean you have 10 of "performance problems", it
me
Am 02.02.2012 19:02, schrieb Stas Malyshev:
> Hi!
>
>> with many hundret active sessions was not a
>> single performance problem
>
> I'm not sure I understand what you are talking about here. Performance is a
> scale,
> not a trigger. If you lose 10% (totally invented number as an example) th
Stefan Esser wrote:
> And there are many many good reasons, why Suhosin must be external to PHP.
> The most obvious one is that the code is clearly separated, so that not
> someone of the hundred PHP commiters accidently breaks a safe guard.
That's not a justification to keep it as a patch.
Safe g
2012.02.02 19:42 Reindl Harald rašė:
> security is THE benefit for ALL users, especially in days where many
> are running crap-code like Joomla/Wordpress with all sorts of plugins
> throwing millions of warning if you run with E_ALL and E_STRCIT
E_STRICT throws notices on properly written code. It
This is off topic, can we stay on focus please?
(and disable these levels if you don't want to see them in your logs)
On Thu, Feb 2, 2012 at 7:42 PM, Tomas Kuliavas
wrote:
> 2012.02.02 19:42 Reindl Harald rašė:
>> security is THE benefit for ALL users, especially in days where many
>> are runnin
Am 02.02.2012 19:42, schrieb Tomas Kuliavas:
> 2012.02.02 19:42 Reindl Harald rašė:
>> security is THE benefit for ALL users, especially in days where many
>> are running crap-code like Joomla/Wordpress with all sorts of plugins
>> throwing millions of warning if you run with E_ALL and E_STRCIT
>
On 02/03/2012 01:59 AM, Stas Malyshev wrote:
> You seem to advocate the approach in which
> performance and convenience can and should be sacrificed to security.
> It is a matter of opinion
Something I don't get here. If there's this issue, and
different tastes, why can't a build flag be used, so
The PHP development team would like to announce the immediate
availability of PHP 5.3.10. This release delivers a critical security
fix.
Security Fix in PHP 5.3.10:
* Fixed arbitrary remote code execution vulnerability reported by
Stefan Esser, CVE-2012-0830.
All users are strongly encoura
Hey.
First, thanks Ondřej, for bringing this to a wider audience :)
On Thu, 2012-02-02 at 13:55 +0100, Ondřej Surý wrote:
> 1. Suhosin patch has an impact on the speed and memory usage. This has
> been documented and even author admits it [1].
>
> 2. It doesn't help our users when reporting b
On 02/02/2012 06:37 PM, Stas Malyshev wrote:
> Hi!it sucks major ass, as
>
>> yes, but suhosin-extension and hardening patch exists since many years
>>
>> the question from a normal user:
>> why are these things not included in the core?
>
> Because some of these things slow down the code and t
(Resurrecting a very old thread. Sorry about the thread necromancy.)
On 8 September 2011 05:20, Rasmus Lerdorf wrote:
> On 09/07/2011 02:12 PM, Stas Malyshev wrote:
>> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
>> itimer implementation at least up to kernel 10.8.0, Ma
Hi!
I've been trying to run down tests/func/005a.phpt failing this
morning, and obviously this is the cause. I don't have a Lion machine
to hand to test this there, but it does look like ITIMER_PROF is
completely broken on OS X 10.6.7 and 10.6.8.
Yes, this test is broken and looks like somethi
On 3 February 2012 12:05, Stas Malyshev wrote:
>> For me at least, tests/func/005a.phpt is the last failing test on
>> PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
>> pre-5.4.0 to help get cleaner test suite results.
>
>
> I really wouldn't want to hold the release for an
On 02/03/2012 01:28 AM, Christoph Anton Mitterer wrote:
> But this wouldn't solve our discussion here... the question would
> still be open, whether Debian sets this flag or not, or whether it
> makes two binary packages.
Now that's something I didn't read from Ondřej's mail, but delivering
the pa
hi,
On Fri, Feb 3, 2012 at 1:48 AM, Soenke Ruempler - Jimdo
wrote:
> _YOUR_ responsibility as the provider (READ: provider) of a
> programming-language is to provide a secure environment in favor a
> micro-optimized performance.
This is in so many ways wrongly formulated. This is what we do,
al
34 matches
Mail list logo
