Hey.
So what's the result of this discussion now?!
^^
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Am 03.02.2012 12:46, schrieb Thomas Goirand:
I think you are under estimating how much work Ondrej has done
already
in the past, and how much *more* work you are asking him to do here,
when the whole PHP team is shouting for help! Yes, adding yet another
build *is more work*, not less.
Well I
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
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/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
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
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
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
25 matches
Mail list logo
