Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57687 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98154 invoked from network); 4 Feb 2012 09:54:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2012 09:54:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=mapopa@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=mapopa@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: mapopa@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-lpp01m010-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:54724] helo=mail-lpp01m010-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 57/5A-08838-7500D2F4 for ; Sat, 04 Feb 2012 04:54:31 -0500 Received: by lagk11 with SMTP id k11so2339664lag.29 for ; Sat, 04 Feb 2012 01:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MstjrIxDW/yypFljNvQU1fZIh5ctgkRRlGHx1bBScxk=; b=jhCd6D8b/GRBxPBwBGk/hRrHGs0lnhG3OM71gA5FXb8c2NmZMKX0cSDeycCol3TH+J rMd0GC9JhOWnus9wnVs1usMGClGvndRci7pAWQQGuc431GpBj0Any8zKJaFh/1yN1/Sj aSEMqWOoPE/Yzj9RAE0G43eQHXN+cjlsIKQLg= MIME-Version: 1.0 Received: by 10.112.25.33 with SMTP id z1mr2825549lbf.7.1328349267224; Sat, 04 Feb 2012 01:54:27 -0800 (PST) Received: by 10.152.133.147 with HTTP; Sat, 4 Feb 2012 01:54:27 -0800 (PST) In-Reply-To: References: <5FB5CFDA-6FE8-4C20-A9B9-7844ED96659B@nopiracy.de> <4F2A9378.70803@thelounge.net> <4F2AC9CA.2070308@sugarcrm.com> <4F2B2ED8.4050900@jimdo.com> <72878E6C-4C17-4D94-9F73-1446769247E1@nopiracy.de> <4F2CEA7E.9010906@sugarcrm.com> <9684A843-5A7F-43BB-BFC2-86F34E27EC3B@nopiracy.de> Date: Sat, 4 Feb 2012 11:54:27 +0200 Message-ID: To: Pierre Joye Cc: Stefan Esser , Stas Malyshev , Soenke Ruempler - Jimdo , PHP internals , "security@php.net" , "zigo@debian.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds From: mapopa@gmail.com (marius adrian popa) 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 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 shows that when you break it there is a secondary layer of defense that protects you in case you use Suhosin. > > I was talking about the compilation security options which are similar > (in some extends) to what Suhosin does (for some features). > >> Pierre it is time for you to come out of the delusional state. You repeatedly claim that everything is now superb. > > No, I said it is different and better than what you have experienced. > And anyone active today in php.net can tell you the same. > >> Do you forget PHP 5.3.7 and PHP 5.3.9 both times there were security vulnerabilities introduced right after the last RC. >> This is a sign that the PHP development process is still not healthy at all. > > So any software having security issues at one point or another is not healthy? > > I consider the opposite, I am very careful when I see a software > without any discovered issues for a long time, a sign of lack of > activities and users. > >> You claim I have personal issues, while I repeatedly tell you the technical reasons why I see it different then you. > > Sorry but I do not see technical issues in this thread, as in > technical explanations about why one given feature is actually a good > thing. I did not see any either in the past discussions. > 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" http://kerneltrap.org/Linux/Pluggable_Security If there is something that needs to be done so php core will be more secure , make it in the core Not words : write RFC(docs),patches with sane techincal disscussions or a pluggable architecture with extensions and rules, something like is done with LSM http://en.wikipedia.org/wiki/Linux_Security_Modules or mod_security in apache I vote with the Debian point of view , less patches means faster releases for php also it means more security and they are using the vanilla core (less suoshin related bugs to support) The goal is : 0 patches and use upstream as much as possible