On Thu, Feb 02, 2012 at 03:59:12PM +0100, Stefan Esser wrote:
So basically all points you bring up are no issues.
The bit about good relationship with upstream seems to hold; especially given
the tone of your responses. It's *very* important for Debian to have a good
working relationship with
On 02/02/12 14:31, Stefan Esser wrote:
considering the fact that you write this email the very same day that a
remote code execution vulnerability in PHP is found that is easy to exploit
from remote and is greatly mitigated by the use of Suhosin you look pretty
stupid. (In case of usage of
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 ste...@nopiracy.de 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
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
* Carlos Alberto Lopez Perez clo...@igalia.com [2012-02-02 14:46]:
On 02/02/12 14:31, Stefan Esser wrote:
considering the fact that you write this email the very same day that a
remote code execution vulnerability in PHP is found that is easy to
exploit from remote and is greatly
On Donnerstag, 2. Februar 2012, Nico Golde wrote:
http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fi
x-for-php-hashtable-collision-dos/
Oh my... :(
sigh.
thanks Stefan, thanks Nico.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject
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
On Thu, Feb 02, 2012 at 03:14:56PM +0100, Stefan Esser wrote:
BTW: You should really really look into the history of PHP security and check
for each of the last 8 years how many features were in Suhosin and later
merged into PHP because of some nasty security problem.
You will see that at
hi Stefan,
On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser ste...@nopiracy.de 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
On Thu, Feb 2, 2012 at 4:49 PM, Pierre Joye pierre@gmail.com wrote:
hi Stefan,
On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser ste...@nopiracy.de 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.
[resent with 7-bit headers. apologies for any mangled names:]
Pierre Joye writes (Re: [PHP-DEV] Suhosin patch disabled by default in Debian
php5 builds):
[...] But so far I failed to see other features in Suhosin that we
need to implement without having more cons than pros.
I know nearly
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
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
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
On 02/02/12 14:43, Carlos Alberto Lopez Perez wrote:
On 02/02/12 14:31, Stefan Esser wrote:
considering the fact that you write this email the very same day that a
remote code execution vulnerability in PHP is found that is easy to exploit
from remote and is greatly mitigated by the use of
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Pierre Joye writes:
[...] But so far I failed to see other features in Suhosin that we need
to implement without having more cons than pros.
I know nearly nothing about PHP security and nothing about Suhosin.
But from what I have read in
On Fri, 3 Feb 2012, Russ Allbery r...@debian.org wrote:
For example, Debian could immediately become a much more secure OS by
enabling SELinux in enforcing mode on all Debian systems. The reason why
we don't do this is that currently that tradeoff doesn't make sense; too
much other stuff
Russell Coker russ...@coker.com.au writes:
SE Linux is supported in critical packages including the kernel,
sysvinit, and cron. So any user who wants to use it can just install
the SE Linux specific packages and rely on the built-in support for SE
Linux in important base packages.
This
19 matches
Mail list logo
