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
Russell Coker 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 compares to the PHP
On Fri, 3 Feb 2012, Russ Allbery 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 doesn't work, to
Ian Jackson 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 this thread, I find this
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 us
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
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
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
[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
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
> >
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 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 a
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 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
* Carlos Alberto Lopez Perez [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 mitigated by the us
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
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
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
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
19 matches
Mail list logo
