Bug#657698: [php-maint] Bug#657698:

[Ondřej Surý]

Hi,

there was a short discussion on the mailing list. It was started by Jan Wagner
(maintainer of php5-suhosin module) here:

http://lists.alioth.debian.org/pipermail/pkg-php-maint/2012-January/009642.html

I then asked on the mailing list about other opinions:

http://lists.alioth.debian.org/pipermail/pkg-php-maint/2012-January/009655.html

and then decided that it's not worth the trouble to support suhosin patch.

The PHP team is undermanned for a very long time, so you are welcome to
join the team, help with squashing the bugs and then prepare and thoroughly
test a patch to build non-suhosin and suhosin SAPI variants in one build.
We (basically I) don't have a resources for that, so the rational decision was
to divert a little less from the upstream.

For other reasons see f.e.:
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/498022

O.

On Sat, Jan 28, 2012 at 21:09, Douglas Calvert  wrote:
> Hello,
>  Why was suhosin disabled in the first place? I have not found any
> information regarding the reasoning. I looked at open and closed php5
> bugs mentioning suhosin and could not find an explanation.
>
> Bug #657697: "php5: suhosin silently disabled" documents the removal
> but does not explain why...
>
>
>
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint



-- 
Ondřej Surý 
http://blog.rfc1925.org/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [php-maint] Bug#657698:

[Christoph Anton Mitterer]

Hi.

I cannot read the those threads right now, as alioth is down... but
anyway...


On Sun, 2012-01-29 at 09:47 +0100, Ondřej Surý wrote:
> The PHP team is undermanned for a very long time
Well I don't wanna tell you how to do your job ;-) ... but wouldn't it
then be better to rather drop some other PHP related parts (not so much
used packages or so)?
IMHO suhosin is really important as it's quite relevant for security.


> For other reasons see f.e.:
> https://bugs.launchpad.net/ubuntu/+source/php5/+bug/498022

Well I know about such complains but usually suhosin disables things for
good reasons, or you can tell it not to do so.
With respect to the performance arguments,... well ideally one should
probably have the choice (with php with suhosin patch, being the
default), but if not, one should rather let people build their own PHP
packages without suhosin, given the expectation that they know what
they're doing, than the other way round.


Were there any troubles in applying the suhosin core patch to PHP? So is
it "just" a matter of making the php5 source package produce binaries
for both -with-suhosin and no-suhosin?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: [php-maint] Bug#657698:

[Ondřej Surý]

On Sun, Jan 29, 2012 at 22:36, Christoph Anton Mitterer
 wrote:
> Were there any troubles in applying the suhosin core patch to PHP?

It still applies cleanly.

> So is it "just" a matter of making the php5 source package produce binaries
> for both -with-suhosin and no-suhosin?

That's exactly what it is not. You need to support every package you
produce, check
the bug reports, you need to communicate with users and with PHP upstream.

I am also quite sure that we don't want to build every extension
twice. So you probably
need to check if it's possible to build the extension just once and use it with
with-suhosin and no-suhosin.

O.
-- 
Ondřej Surý 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [php-maint] Bug#657698:

[Christoph Anton Mitterer]

On Sun, 2012-01-29 at 22:56 +0100, Ondřej Surý wrote:
> > Were there any troubles in applying the suhosin core patch to PHP?
> It still applies cleanly.
So the effort it made you was in tracing bugs in software that didn't
work with suhosin?
Isn't this rather the business of upstream of those packages (and/or
suhosin itself)?

I guess suhosin.simulation=On doesn't "disable" the core patch (or it's
enforcement), does it?

My idea was just, that if applying the patch uses to work well, than you
could rather enable it per default, and just point those experiencing
problems to rebuild their own packages.


> > So is it "just" a matter of making the php5 source package produce binaries
> > for both -with-suhosin and no-suhosin?
> That's exactly what it is not. You need to support every package you
> produce, check
> the bug reports, you need to communicate with users and with PHP upstream.
Uhm... yeah,.. of course I cannot judge this, if you had that many
troubles with it. :-(


> I am also quite sure that we don't want to build every extension
> twice. So you probably
> need to check if it's possible to build the extension just once and use it 
> with
> with-suhosin and no-suhosin.
That could become a problem. But I don't know, I'm rather a PHP user
(anything else but an expert) and I'd even prefer not having to be a
user.
Having had some bad experiences with security in PHP and PHP
applications I used to be quite happy about suhosin, which is also why I
now try to convince you maintainers to add it back ;)

Anyway... if you think that extensions build for with-suhosin don't work
with a non-suhosin php... then
a) you'd have to break all those php5- packages out there already now,
right?
b) if you "support" building your packages with suhosin then (with that
option) the resulting packages should also somehow break all others
(that have not been rebuilt).


Perhaps you can post an RFH on d-d? I guess there are many guys out
there using php that like suhosin and that perhaps haven't even noticed
yet that is gone.


What about *buntu? They just take Debian's package as is, right?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: [php-maint] Bug#657698:

[Christoph Anton Mitterer]

Hi Stefan.

Unfortunately Debian's php maintainers had to drop the suhosin core
patches (for now), as far as I understand mainly because of lack of
man-power.

I've opened a bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698
where I asked (or begged ;) ) them to add it back or (even better),
provide packages for both, i.e.:
with suhosin core patch applied (being the "default"):
php5-*

without suhosin core patch applied (for those who have troubles with
it):
php5-*-nosuhosin


Now the question arose, whether any php extensions would notice and
would have to be (re-)compiled for each of the two?
So basically, is the ABI identical or not?


Ideally of course, suhosin core patch would get merged upstream, perhaps
with a runtime option to disable it, but I guess this remains dreaming,
right?


Thanks,
Chris.

btw: As long as Debian no longer applies suhosin core patch,...
somewhere on the suhosin website you note that it would be automatically
part of PHP in Debian; perhaps one should note that this may no longer
be the case, in order not to lead users to wrong assumtions.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: [php-maint] Bug#657698:

[Stefan Esser]

Hello Christoph,

> Unfortunately Debian's php maintainers had to drop the suhosin core
> patches (for now), as far as I understand mainly because of lack of
> man-power.

Yeah it is really amusing that Debian's PHP maintainers spend hours/days on 
writing emails about dropping Suhosin and voting on it. Then spend more time on 
patching their build scripts to no longer ship Suhosin by default. Then spend 
even more time because they broke the build by removing Suhosin… Instead of 
just leaving the patch inside which would have eaten no time at all.

> I've opened a bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698
> where I asked (or begged ;) ) them to add it back or (even better),
I can understand that you as a Debian user are sad about the fact that Debian's 
PHP maintainers decided that security is not important.
However from my point of view it is actually better if Debian does not ship 
Suhosin by default. That might stop them from spreading nonsense like Suhosin 
is unmaintained/upstream is not responsive etc…

> Now the question arose, whether any php extensions would notice and
> would have to be (re-)compiled for each of the two?
> So basically, is the ABI identical or not?
The Suhosin ABI is identical. However the Suhosin patch increases the security 
of PHP extensions if they are compiled against the Suhosin PHP source, because 
different macros are defined so that PHP's internal format string functions are 
used, instead of the system's. This is a protection against format string 
vulnerabilities.

> Ideally of course, suhosin core patch would get merged upstream, perhaps
> with a runtime option to disable it, but I guess this remains dreaming,
> right?
No that will never happen, which is a good thing. You can already 
disable/enable several Suhosin-Patch features like the memory canaries by just 
defining different environment variables before starting PHP.
The Debian PHP maintainers should know all about this, because they patched 
that code some years ago and made it insecure.

> btw: As long as Debian no longer applies suhosin core patch,...
> somewhere on the suhosin website you note that it would be automatically
> part of PHP in Debian; perhaps one should note that this may no longer
> be the case, in order not to lead users to wrong assumtions.

No such message is anywhere on the website. The website only says that there 
are Suhosin packages in Debian, not that it is automatically selected.
Therefore there is no need to fix it.

Regards,
Stefan Esser


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [php-maint] Bug#657698:

[Christoph Anton Mitterer]

On Mon, 2012-01-30 at 23:02 +0100, Stefan Esser wrote:
> Yeah it is really amusing that Debian's PHP maintainers spend
> hours/days on writing emails about dropping Suhosin and voting on it.
> Then spend more time on patching their build scripts to no longer ship
> Suhosin by default. Then spend even more time because they broke the
> build by removing Suhosin… Instead of just leaving the patch inside
> which would have eaten no time at all.
Well ok... I guess they have their reasons, even if they just need to
constantly answer people, who report (invalid) bugs, just because they
denied some function via suhosin, which their application needs.

So I guess you don't mean your "criticism" serious :-) ... thei're doing
all this in their spare time and maintaining a big package like PHP is
surely some effort.


> I can understand that you as a Debian user are sad about the fact that
> Debian's PHP maintainers decided that security is not important.
Well one could argue, that if manpower is just not available, it's
really better to drop it, than having it in, but perhaps in a
non-functional state.


> However from my point of view it is actually better if Debian does not
> ship Suhosin by default. That might stop them from spreading nonsense
> like Suhosin is unmaintained/upstream is not responsive etc…
Uhm.. yeah I haven't the big overview, but at least I haven't read any
such claims.

> 
> The Suhosin ABI is identical.
This is good news..


> However the Suhosin patch increases the security of PHP extensions if
> they are compiled against the Suhosin PHP source, because different
> macros are defined so that PHP's internal format string functions are
> used, instead of the system's. This is a protection against format
> string vulnerabilities.
So does this mean that you really have to compile all the extensions
against a suhosin patched PHP in order to gain these (security)
benefits... or are they just transparently used when suhosin core pathc
was applied; or not used, if not?



> No that will never happen, which is a good thing. You can already
> disable/enable several Suhosin-Patch features like the memory canaries
> by just defining different environment variables before starting PHP.
Is this somewhere documented?
btw: I remember some undocumented features of suhosin, IIRC,
suhosin.server.strip is not documented int the website.


> No such message is anywhere on the website. The website only says that
> there are Suhosin packages in Debian, not that it is automatically
> selected.
Ah,.. you're right :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: [php-maint] Bug#657698:

[Christoph Anton Mitterer]

On Tue, 2012-01-31 at 04:50 +0800, Thomas Goirand wrote:
> Do you have some skills
> that you could lend for this work?
Well as said, I'm really no PHP expert and basically just forced to use
it ;) ...


> If you didn't get in touch with upstream and not pushing for this to
> happen, yes you are dreaming! I really would recommend you to do such
> communication. Maybe upstream will only take few of the features, but
> that's be nice already.
Well... I guess Stefan would have to push for this, as maintainer of
suhosin,... and probably it's difficult to get it merged,... see similar
problems with PaX<->Linux kernel.


> If you aren't participating to the maintenance of PHP in
> Debian, at least you can try to get in touch with upstream for suhosin
> and get them amend their site. That would really be some help.
> 
> But if I'm not mistaking, one of the other reasons why we're going on
> the direction to drop the suhosin patch/modules, is because upstream
> isn't reactive enough. So good luck with the sohosin website update!

Well it seems Stefan is listening now,... if all calm down a bit and be
friendly to each other again, the real goal could be reached:

More security for more end users.

I guess this is what Debian maintainers want (otherwise they wouldn't
have added the patch in the first place) and this is what Stefan wants
(otherwise he wouldn't have written it).

And it's not just the Debian users, that would profit, but also Ubuntu
and (probably) all other derivatives.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: [php-maint] Bug#657698:

[Thomas Goirand]

On 01/31/2012 06:02 AM, Stefan Esser wrote:
> I can understand that you as a Debian user are sad about
> the fact that Debian's PHP maintainers decided that
> security is not important.
> However from my point of view it is actually better if
> Debian does not ship Suhosin by default. That might stop
> them from spreading nonsense like Suhosin is
> unmaintained/upstream is not responsive etc

Please calm down. This is *not* the way to make your point. I might have
been the one who used the bad wording "unresponsive" (based on what
others wrote), if so, then sorry, you've just proven me wrong.

But if you continue with this tone, the only thing that is going to
happen is that instead of saying that upstream is unresponsive, we'll say:

"upstream isn't friendly and replies aggressively on the bug tracker"

You've proven that you are responsive, that's good, and can potentially
reverse the decision if you are ready to help for the packaging. Don't
waste the opportunity! The main reason which this discussion was started
was *the lack of man power*, so if you can do the work...

Also, what you might want to do to avoid the same issue again, would be
registering this list and reading it often, don't you think?

By the way, I've been asking here, and I didn't get a satisfying answer,
so I'd like to ask you as well. I'd be very happy to have your opinion
as upstream author. Do you think that suhosin is still valuable when
running PHP as CGI-BIN, in a chroot? If so, can you explain why?

Thomas Goirand (zigo)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698:

[Douglas Calvert]

Hello,
 Why was suhosin disabled in the first place? I have not found any
information regarding the reasoning. I looked at open and closed php5
bugs mentioning suhosin and could not find an explanation.

Bug #657697: "php5: suhosin silently disabled" documents the removal
but does not explain why...



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: php 5.4.x suhosin

[Christoph Anton Mitterer]

Hi.

It seems that there's "initial" support for 5.4.x PHPs in the suhosin 
git now.


I haven't checked due to lack of time, but does anyone now, whether 
suhosin would have prevent the most recent disastrous security hole in 
PHP? If so,... would be a strong argument supporting my wish in #657698.



Cheers,
Chris.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: php-suhosin packages for Debian

[Thorsten Glaser]

Hi,

I’d also like the idea of two packages, if people cannot
be convinced to add it back, at least. Though, I wanted
to have a look at just rebuilding the normal packages
with the patch applied, then the extensions we use against
that, but failed to find a suhosin patch for PHP 5.4 – is
there one, Stefan?

bye,
//mirabilos • Hat: FusionForge/Evolvis developer
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: Bug#663954: php 5.4.x suhosin

[Alexander Wirt]

On Wed, 09 May 2012, Christoph Anton Mitterer wrote:

> Hi.
> 
> It seems that there's "initial" support for 5.4.x PHPs in the
> suhosin git now.
> 
> I haven't checked due to lack of time, but does anyone now, whether
> suhosin would have prevent the most recent disastrous security hole
> in PHP? If so,... would be a strong argument supporting my wish in
> #657698.
nothing changed to #669972. 

We won't do uploads of unreleased suhosin. Full stop.

Alex
 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: Bug#663954: php 5.4.x suhosin

[Christoph Anton Mitterer]

On Wed, 2012-05-09 at 22:13 +0200, Alexander Wirt wrote:
> nothing changed to #669972.
Ah, I haven't seen that one,... nevertheless it's good to have my note
about progress on the upstream side and your note about #669972 int
these bugs now.


> We won't do uploads of unreleased suhosin.
Yeah,... well guess that's up to you... but it seems as this is actually
some final version (at least according to the changelog) and Stefan just
haven't made a tarball out of it yet.

> If it has security problems some php * will start a
> debian shitstorm
Well that can always happen, right? Even if it's in the form of a
tar.something ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: [php-maint] Bug#657698: Meetoo, make suhosin patch on php5 enabled by default or make it as easy as possible to install

[Ondřej Surý]

Please everybody don't *meetoo*. This is not a popularity contest.

There was people meetooing for removal when suhosin was added, let's not
do it over again but in different direction.

O.

On Tue, Jan 31, 2012 at 12:30, Jesse Molina  wrote:
>
> Just doing a meetoo here and saying that the removal of the suhosin patch on
> php5 is not a good thing for me, though I now understand why it was removed,
> thanks to this bug filing.  I was thrilled when it was included by default
> the first time around.
>
> thanks
>
> --
> # Jesse Molina
> # Mail = je...@opendreams.net
> # Page = page-je...@opendreams.net
> # Cell = 1.602.323.7608
> # Web  = http://www.opendreams.net/jesse/
>
>
>
>
>
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint



-- 
Ondřej Surý 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: Suhosin patch disabled by default in Debian php5 builds

[Ondřej Surý]

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 disable
suhosin patch here.

Please keep the discussion civil and on the technical level and if you
want to engage in deeper discussion please try to keep it isolated in
pkg-php-ma...@lists.alioth.debian.org and 657...@bugs.debian.org, so
we don't flood cross-post. [Sorry for such huge initial cross-post.]

There are already some reasons listed here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698#15

The manpower issue which was mentioned several times is not the only
one (it mainly comes to mind if we have to keep to sets of packages w/
and w/o suhosin). Although the pkg-php team is always looking for new
victims^Umembers.

I'll try even harder to list more reasons, why I have changed my mind
over a time regarding the suhosin patch:

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 bugs to upstream - the
usual answer is - try if that happens with vanilla php.

3. Stefan's relationships with PHP upstream (and vice versa)[1] isn't
helping very much - and I think we (pkg-php) have improved our
relationship with upstream in past few years a lot.

4. PHP has improved a lot, in fact I haven't seen a canary report in
past few years (probably 5.3.x). Also there are very few segfaults
reported in 5.3 (compared to 5.2 which was a living nightmare from
what I remember).

5. Keeping our code close to upstream and to other linux distros
(Fedora - no, Suse - optional) is a way how to provide our users with
consistent behaviour across the Linux ecosystem.

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
security or it is just a burden in the general installations now.

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 definitive list, but it just show that

P.S.: Also see stas reply[5] about valgrind.

Links:
1. 
http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php
2. 
https://bugs.php.net/search.php?search_for=suhosin&boolean=0&limit=90&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=PHP&php_os=&phpver=5.3&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0
3. https://bugs.php.net/bug.php?id=60216
4. https://bugs.php.net/bug.php?id=60935
5. 
http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/

-- 
Ondřej Surý 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: Suhosin patch disabled by default in Debian php5 builds

[Christoph Anton Mitterer]

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 bugs to upstream - the
> usual answer is - try if that happens with vanilla php.
>
> 5. Keeping our code close to upstream and to other linux distros
> (Fedora - no, Suse - optional) is a way how to provide our users with
> consistent behaviour across the Linux ecosystem.


I guess these three could be solved by my suggestion of having separate
packages with and without the suhosin core patched applied.
In case of (1), people can just choose. This is just what Stas Malyshev
talked about. Some people may depend on speed/memory... some absolutely
not (just take my little DAViCal server which is responsible for #657698
and this discussion ;) ).

In case of (2), one can ask them to reproduce it first with the
non-suhosin package.


> 3. Stefan's relationships with PHP upstream (and vice versa)[1] isn't
> helping very much - and I think we (pkg-php) have improved our
> relationship with upstream in past few years a lot.

I don't know any details here, but as long as his patched work well on
the vanilla source,... it shouldn't be a major issue for Debian, right?



I agree with Stefan, that having such guards is a good thing. This is to
some extent why things like grsceurity, PaX, and similar exist. There
always was need for them,.. and I guess there allways will be.
Just saying "there were only few security holes recently" is not an
argument. An argument would be "most/all features of suhosin are now
integrated or handled similarly in PHP anyway".
I think that also his argument of the advantage of having such a patch
external is not to stupid,... of course it makes problems in other
corners.

Btw: Stefan, while I understand that you may feel offended that suhosin
it dropped/attacked/criticised, I guess it doesn't help that you use
unfriendly words.
And the same applies to those who did vice versa (to Stefan).


On Thu, 2012-02-02 at 15:26 -0800, 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, too much
> other effort is required, and we're not in a position to enforce
> that technology, even if it would increase security.

I don't want to open a discussion about whether SELinux or some other
framwork is THE answer ;-) but I always had the impression that the
blocker here was rather that there is (which is also a good think) no
single dictator in Debian who can really say: All maintainers, listen
up, go an support SELinux in your packages.
(Which RedHat can do).

Apart from that, I fully agree with your arguments.


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, they can either redirect
people to upstream, or the no suhosin version or even (if time is
available) try to help.

I have however still not understood, whether one would need to compile
the extensions for both versions, Stefan?!




On Fri, 2012-02-03 at 10:45 +1100, Russell Coker wrote:
> 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/Suhosin situation where users who want that
> have no option other than to download the source and the Suhosin
> patch and build their own packages.

Phew,.. but is it really a good idea to let this be done by innocent
end-users?! I mean this IS just why the critical packages support
SELinux and don't require the the users to do it themselves.
Analogously, this applies to the PHP core packages, IMHO.




On Fri, 2012-02-03 at 04:11 +0800, Thomas Goirand wrote:
> Something I don't get here. If there's this issue, and
> different tastes, why can't a build flag be used, so
> that you can choose security or speed depending on your
> needs? If you do some:
> 
> #ifdef ENABLE_SLOWER_SUHOSIN_SECURITY
> 
> in the controversial parts, then I don't see how this
> would be of trouble for anyone to have Suhosin included
> in upstream PHP.
Absolutely +1 ;-)

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.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: Suhosin patch disabled by default in Debian php5 builds

[Thomas Goirand]

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, they can either redirect
> people to upstream, or the no suhosin version or even (if time is
> available) try to help.
>   
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.

Ondrej's post is mostly motivated by his lack of time (please, Ondrej,
correct
me if I'm wrong), and the fact that for him, continuing to maintain PHP with
Suhosin is difficult and time consuming (he made few points explaining why).

If Stefan was ready to help (or someone else), both in maintaining the
patch and extension in Debian, and also help with the packaging of PHP
itself, and with bug reports, triaging and such, it would be totally
different.

But as much as I can tell, neither Stefan or anyone else seem to be willing
to make the necessary efforts.

I've bring that up with Stefan, and yet didn't receive a reply from him on
this topic.

Thomas




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: Suhosin patch disabled by default in Debian php5 builds

[Christoph Anton Mitterer]

Hey.

So what's the result of this discussion now?!

^^

Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stefan Esser]

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
> security or it is just a burden in the general installations now.

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 Suhosin-Extension in default config, it is even completely 
killed).

Just saying.


Regards,
Stefan Esser




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Pierre Joye]

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
>> the real question is if the suhosin is still really helping with PHP
>> security or it is just a burden in the general installations now.
>
> 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 Suhosin-Extension in default config, it is even 
> completely killed).

Another very important part of Ondrej's email was:

"Please keep the discussion civil and on the technical level"

And at this point, I may suggest you to keep such posts for yourself.

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 itself better and safer instead of distracting us
and our users with custom patches or extensions.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Carlos Alberto Lopez Perez]

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 Suhosin-Extension in default config, it is even 
> completely killed).
> 
> Just saying.
> 

I think that you words are out of tone, there is not need to be unpolite


And where is such exploit??? I don't see any CVE

http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74



-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stefan Esser]

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 reason why Suhosin exists is because there will ALWAYS be bugs. And 
because that is a fact you must have safe guards in case something goes wrong.
Suhosin/HPHP provides this safe guard for 8 years to the PHP community.

Ideas like: I haven't seen much bugs lately so lets drop all the safe guards is 
like not paying for your life insurance anymore, because you haven't died too 
often recently.

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 least 2 features of Suhosin per year were merged into PHP.

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.

Regards,
Stefan Esser


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stefan Esser]

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 definitive list, but it just show that
> 
> P.S.: Also see stas reply[5] about valgrind.
> 
> Links:
> 1. 
> http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php
> 2. 
> https://bugs.php.net/search.php?search_for=suhosin&boolean=0&limit=90&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=PHP&php_os=&phpver=5.3&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0
> 3. https://bugs.php.net/bug.php?id=60216
> 4. https://bugs.php.net/bug.php?id=60935
> 5. 
> http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/

1) You understand that Hardening-Patch is not Suhosin-Patch, do you?

2) Maybe you should also search for: Have Debian, then use a clean PHP not a 
broken Debian build

Bug 3 -> is not a bug in Suhosin, it is the fact that the 
suhosin.executor.max_depth function was not set correctly. Reading the 
documentation helps: 
http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.max_depth

Bug 4 -> the guy is actually writing inside the bug report that the problem 
occurs with and without Suhosin

5) You can just start PHP with the environment variable 
SUHOSIN_MM_USE_CANARY_PROTECTION=0 and can use valgrind.


So basically all points you bring up are no issues.

Regards,
Stefan Esser





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Andrea Bolognani]

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 least 2 features of Suhosin per year were merged into 
> PHP.

If that’s the case, then you have nothing to worry about.

As more and more Suoshin features are merged into mainline PHP, Debian’s
PHP package will get more and more secure. That’s the way it happens for
many other packages, I fail to see why PHP should be treated differently.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: Digital signature

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Pierre Joye]

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 the idea behind Suhosin, 
> the concept of exploit mitigations.

Let me disagree with your way of doing things without telling me that
I do not understand what you do. It is two different concepts. I also
perfectly understand the goals of Suhosin, the technical as well as
the non technical ones. The anonymity of a project is not always
helpful.

> The only reason why Suhosin exists is because there will ALWAYS be bugs.

Indeed, so it is for Suhosin as well.

> 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 least 2 features of Suhosin per year were merged into 
> PHP.

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.

> 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.

I would be the happiest man on Earth if PHP would have hundred active
PHP contributors. As a matter of fact, we have like 3-4 active weekly,
less than 10 yearly and maybe around 15 for the 'let commit something'
area.

While we discuss about the reasons why I do not think Suhosin is not
the right way, let start from the beginning.

I understand why you left the security team and the php project years
ago. Back then I was not on the security team, so I won't comment this
period (and I would have partially agreed with you). However, I am
part of this team since some years now and I (along with other) have
been pushing drastic changes in the way we work, for releases or
security issues in particular. You are ignoring these changes and
progresses.

For example the Release RFC (https://wiki.php.net/rfc/releaseprocess):

 . does not allow new features after x.y.0 final

 . enforce quick release when a flaw is discovered
   much easier to do as no noise commits will be present

 . many other good things

Only the two first points will drastically increase the quality and
safety of our releases. The reason is that the amount of unnecessary
commits will be null, or almost null. That kills the argument about
'hundred of commit(ers) breaking PHP'. It also helps to get fixes out
sooner rather than later.

Many features are making their way to PHP as well, on a case by case
basis. We have changed and we are on the right track since quite some
time already. If you have features that you consider that it must be
in the core, then let discuss it, on this list. But so far I failed to
see other features in Suhosin that we need to implement without having
more cons than pros.

I am also convinced that these new policies will also allow
distributions to update to the latest release of a given branches
instead of having to backport fixes to their tree. And that alone is a
huge step forward.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[jpauli]

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
> >> discussion.
> >
> > I know that for many years you have not understood the idea behind
> Suhosin, the concept of exploit mitigations.
>
> Let me disagree with your way of doing things without telling me that
> I do not understand what you do. It is two different concepts. I also
> perfectly understand the goals of Suhosin, the technical as well as
> the non technical ones. The anonymity of a project is not always
> helpful.
>
> > The only reason why Suhosin exists is because there will ALWAYS be bugs.
>
> Indeed, so it is for Suhosin as well.
>
> > 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 least 2 features of Suhosin per year were merged
> into PHP.
>
> 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.
>
> > 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.
>
> I would be the happiest man on Earth if PHP would have hundred active
> PHP contributors. As a matter of fact, we have like 3-4 active weekly,
> less than 10 yearly and maybe around 15 for the 'let commit something'
> area.
>
> While we discuss about the reasons why I do not think Suhosin is not
> the right way, let start from the beginning.
>
> I understand why you left the security team and the php project years
> ago. Back then I was not on the security team, so I won't comment this
> period (and I would have partially agreed with you). However, I am
> part of this team since some years now and I (along with other) have
> been pushing drastic changes in the way we work, for releases or
> security issues in particular. You are ignoring these changes and
> progresses.
>
> For example the Release RFC (https://wiki.php.net/rfc/releaseprocess):
>
>  . does not allow new features after x.y.0 final
>
>  . enforce quick release when a flaw is discovered
>   much easier to do as no noise commits will be present
>
>  . many other good things
>
> Only the two first points will drastically increase the quality and
> safety of our releases. The reason is that the amount of unnecessary
> commits will be null, or almost null. That kills the argument about
> 'hundred of commit(ers) breaking PHP'. It also helps to get fixes out
> sooner rather than later.
>
> Many features are making their way to PHP as well, on a case by case
> basis. We have changed and we are on the right track since quite some
> time already. If you have features that you consider that it must be
> in the core, then let discuss it, on this list. But so far I failed to
> see other features in Suhosin that we need to implement without having
> more cons than pros.
>
> I am also convinced that these new policies will also allow
> distributions to update to the latest release of a given branches
> instead of having to backport fixes to their tree. And that alone is a
> huge step forward.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
In fact, I agree that it'd be a good idea to discuss more widely PHP
Security , why not through specific RFCs, with POCs of each ideas/concepts
, so that people could comment on them, and approve/decline the
concepts/patches :)

Julien.P

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Ian Jackson]

[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 nothing about PHP security and nothing about Suhosin.

But from what I have read in this thread, I find this kind of argument
very unconvincing.  Surely the time to drop something like Suhosin
would be when PHP stops actually having bugs which are mitigated by
Suhosin.  Not when the PHP project claims to have improved its
processes so that these bugs won't occur any more.  

The decision should be based on the existence or not of the
vulnerabilities, and whether Suhosin in actual fact helps.

Ian.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Stas Malyshev]

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 performance cost and other risks,
into PHP its necessity to the user needs to be proven and outweigh the
problems it causes. You seem to advocate the approach in which
performance and convenience can and should be sacrificed to security. It 
is a matter of opinion, and each one has its own validity. We probably 
would have for now to agree to disagree here.


That said, I personally would be happy to see more participation from
you - including and especially contributing and maintaining parts of
Suhosin patch that do not have high costs and user issues associated
with them and are not controversial - I think it would benefit PHP a
lot. Of course, it's your decision, but I think that would be better
both for PHP security and PHP users which have little interest in what
belongs where and why, but right now the only person who can maintain
and support any line of code in Suhosin is you, which is not always
helpful to the users.


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.


There's no "hundred PHP committers" except in theory. In practice, 
number of people regularly committing to relevant part of the core is 
probably less then 10.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Ángel González]

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 guards could prefectly be skipped by a commit which changed near
code, reestructures the function or creates a different path, *even if
the patch still applies*.
So you would still need to check for all kind of unexpected changes anyway.

If it were in core, at least anyone changing the related code would
realise that it's there, and could take that into account for not
breaking it. If it's maintained by someone else as a patch, that simply
won't happen.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Thomas Goirand]

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
that you can choose security or speed depending on your
needs? If you do some:

#ifdef ENABLE_SLOWER_SUHOSIN_SECURITY

in the controversial parts, then I don't see how this
would be of trouble for anyone to have Suhosin included
in upstream PHP.

Cheers,

Thomas Goirand (zigo)




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Carlos Alberto Lopez Perez]

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 Suhosin you look pretty 
>> stupid. (In case of usage of Suhosin-Extension in default config, it is even 
>> completely killed).
>>
>> Just saying.
>>
> 
> I think that you words are out of tone, there is not need to be unpolite
> 
> 
> And where is such exploit??? I don't see any CVE
> 

Answering myself:


 Original Message 
From: Tomas Hoger 
To: OSS Security 
Cc: secur...@php.net, Stefan Esser 
Subject: [oss-security] PHP remote code execution introduced via HashDoS fix

Hi!

Internets are buzzing with info on the PHP flaw found by Stefan Esser
in the fix for CVE-2011-4885.

http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/
http://www.h-online.com/security/news/item/Critical-PHP-vulnerability-being-fixed-1427316.html
http://svn.php.net/viewvc?view=revision&revision=323007

This got CVE-2012-0830 assigned earlier today.  This is sent to make
the assignment public and avoid possible duplicate assignment.

-- 
Tomas Hoger / Red Hat Security Response Team




-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Russ Allbery]

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 kind of argument
> very unconvincing.  Surely the time to drop something like Suhosin would
> be when PHP stops actually having bugs which are mitigated by Suhosin.
> Not when the PHP project claims to have improved its processes so that
> these bugs won't occur any more.

> The decision should be based on the existence or not of the
> vulnerabilities, and whether Suhosin in actual fact helps.

Well, from the Debian perspective, it also needs to be based on the
maintainability of the patch and on the benefit versus complexity
tradeoff.

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, too much other effort is required, and
we're not in a position to enforce that technology, even if it would
increase security.

I think the maintainers need to make a judgement call about whether the
problems and additional work required to maintain packages with the patch
integrated, for both the Debian maintainers and the PHP user community on
Debian, is justified by the benefits provided by the patch.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Russ Allbery]

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/Suhosin situation where users who want that
> have no option other than to download the source and the Suhosin patch
> and build their own packages.

> For the analogy you want to make a better option would be GR Security
> which is not supported in the Debian kernel and won't be supported in
> the forseeable future.

Good point, thank you.  That's a better analogy.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Russell Coker]

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, too much other effort is required, and
> we're not in a position to enforce that technology, even if it would
> increase security.

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/Suhosin situation where users who want that have no 
option other than to download the source and the Suhosin patch and build their 
own packages.

For the analogy you want to make a better option would be GR Security which is 
not supported in the Debian kernel and won't be supported in the forseeable 
future.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

[Kiall Mac Innes]

Hi John,

Ondřej (One of the Debian PHP maintainers) listed 5 or 6 reasons in the
initial email in this thread.

Honestly, I can't think of a good reason for Debian or anyone else to
include 3rd party patches, whatever the patches purpose, in the default PHP
packages.

I would argue that, if people want 3rd party patches they should either:

A) Apply the patch themselves. or:
B) Petition the author and php-core to have the patch applied upstream, to
everyone's benefit.

This is the only way to ensure IMO that everyone is using "the same PHP",
or they have explicitly opted to use some 3rd party code.

Thanks,
Kiall


On Sat, Feb 4, 2012 at 5:21 PM, John Crenshaw wrote:

> OK, All the mud slinging is getting really silly (on *both* sides).
> There's no need to denigrate others because you don't agree with them.
> There's no point in arguing about who isn't a team player or who works for
> which evil multinational corporation. Nobody is attacking anybody else by
> suggesting that Suhosin is or is not critical, and none of that really
> matters anyway.
>
> I may have missed something, but has anyone asked *why* the patch was
> disabled? I think I could make a good guess, but I haven't seen even the
> slightest hint of the actual reasons in this email chain (though I could
> easily have missed it entirely).
>
> IMO we should try to focus on:
> 1. What are the pros vs. cons of enabling the Suhosin patch by default?
> 2. Why did the Debian team opt to disable it?
> 3. Are there better solutions that should be considered and recommended?
>
> John Crenshaw
> Priacta, Inc.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Bug#657698: [PHP-DEV] Re: Suhosin patch disabled by default in Debian php5 builds

[Florian Anderiasch]

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 packages with and without suhosin would, while being more work,
certainly the most helpful way for users. Then again I'd gladly help if
there's anything of this additional work that can be done.

I'd prefer to have Debian's default php5 package with Suhosin as usual,
but I'm hardly the one making demands or suggestions here.

I'm with Soenke (different mail in this thread) - better keep the
securest-possible package by default. When I need performance, I'm
rolling my own php anyway - no matter what base system or package format.

Greetings,
Florian



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Ondřej Surý]

Here's some additional reading for reasons why one might drop the
suhosin patch from official repositories written by the official
maintainer of PHP in Archlinux:

https://pierre-schmitz.com/php-5-4-1-in-suhosin-out/

(This is not meant as start of flamewar - just a pointer.  If you
disagree, please discuss there, not here.  Thanks.)

O.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Christoph Anton Mitterer]

On Mon, 2012-06-11 at 10:58 +0200, Ondřej Surý wrote:
> https://pierre-schmitz.com/php-5-4-1-in-suhosin-out/
Thanks for the pointer... seems to be rather administrative issues he
notes, less technical problems of it, right?!

Apart from all the arguments pro and contra suhosin and totally ignoring
the current lack of time by the Debian PHP maintainers... I personally
think that _ideally_ one would have packages for both in Debian, with
and without suhosin.

There are always people who want either or the other... some may want
the "extra security" some count on speed and surely there are much more
further arguments.


I'd also like to hear more info from Stefan (guess he may still read
this bug thread)... about the timeline for full 5.4 support... and it
would be great if he could also move the core patch to some public
repo :)


Cheers :-)
Chris,


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: php5: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Christoph Anton Mitterer]

affects 657698 php5-suhosin
stop

Hi.

As far as I can see the suhosin extension doesn't work without the core
patch, right?
Therefore, adding an affects for the php5-suhosin package.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#657698: php5: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Christoph Anton Mitterer]

Hi again.

1) We recently saw several CVEs on php5...

I think it would be nice for the records in this ticket, to see which 
of them would have been avoided by the use of suhosin-core-patch, 
suhosin-module or both.

Is there an overview? Stefan, any ideas?


And rather unrelated to that particular Debian bug:
2) I know we talked about that before and there have been probably 
plenty of discussions elsewhere where I was not involved, but...

... now that PHP 5.4 is out ...

Is there any chance or at least space to talk between suhosin and php 
upstream, about an inclusion of the former in the later (i.e. on a basis 
that one can enable/disable it via an ini setting or so)?
I know there are arguments pro and contra such a inclusion,... but IMHO 
the biggest one is security for the end-user, and that would clearly be 
improved by including it upstream (and perhaps even enabling it per 
default).



Cheers,
Chris.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: php5: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Christoph Anton Mitterer]

Package: php5
Version: 5.3.9-3
Severity: wishlist


Hi.

Having the suhosin patch enabled per default used to be a very good thing
and probably greatly increased security of PHP installations.

In this versions, it seems you've disabled the patch.

I don't know the reasons but I'm very sad about it.
Even though you've added that PHP5_SUHOSIN=no/yes option to the rules file
it would mean some effort for people to reactivate this (manually making
packages and so on).

Could you:
a) Just re-enable it per default (for security reasons); if some people have 
problems
with it, they should rather try to fix this upstream... or such people could 
manually
build their packages and disable suhosin in it.

b) Provide packages for both, which conflict each other, and provide the same 
names.
One could have e.g.
php5, php5-cgi, php5-cli, etc. => suhosin enabled
php5-nosuhosin, php5-cgi-nosuhosin, php5-cli-nosuhosin, etc. => suhosin disabled
That way, per default packages with suhosin enabled (which should be the sane 
default)
would get installed, but people have still the possibility to take the other 
packages
if they like; without any manual compilations.


Cheers,
Chris.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: php5: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Carlos Alberto Lopez Perez]

On -10/01/37 20:59, Ondřej Surý wrote:
> On Sun, Jan 29, 2012 at 22:36, Christoph Anton Mitterer
>  wrote:
>> Were there any troubles in applying the suhosin core patch to PHP?
> 
> It still applies cleanly.
> 
>> So is it "just" a matter of making the php5 source package produce binaries
>> for both -with-suhosin and no-suhosin?
> 
> That's exactly what it is not. You need to support every package you
> produce, check
> the bug reports, you need to communicate with users and with PHP upstream.
> 
> I am also quite sure that we don't want to build every extension
> twice. So you probably
> need to check if it's possible to build the extension just once and use it 
> with
> with-suhosin and no-suhosin.
> 
> O.

Hello,

I have just noticed this today when upgrading...


I am really sad to see this feature removed from Debian.


After reading this bug report I understand that:

 * Suhosin patch was removed because lack of man-power to maintain it
 * The main problem maintaining Suhosin were related to bugs from users
complaining about broken php applications.


So, if suhosin was creating problems for some users why not simply
ship the configuration of php.ini with "suhosin.simulation = On" by default?


http://myeasylinux.wordpress.com/2010/10/25/disable-suhosin/


This would effectively disable suhosin patch (so no more users would
complain about suhosin breaking their applications) meanwhile this still
would allow the rest of users that are worried about security to enable
suhosin by just changing one line in the configuration.



Or I am missing something?




-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Bug#657698: php5: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Ondřej Surý]

> Or I am missing something?

Yes, you are. You are mixing suhosin patch and suhosin extension. Suhosin patch
cannot be disabled at runtime

O.
-- 
Ondřej Surý 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: [php-maint] php5: re-enable suhosin patch or add separate packages with suhosin patch enabled per default

[Thomas Goirand]

On 02/02/2012 05:13 AM, Carlos Alberto Lopez Perez wrote:
> Hello,
> 
> I have just noticed this today when upgrading...
> 
> I am really sad to see this feature removed from Debian.
> 
> 
> After reading this bug report I understand that:
> 
>  * Suhosin patch was removed because lack of man-power to maintain it
>  * The main problem maintaining Suhosin were related to bugs from users
> complaining about broken php applications.
> 
> 
> So, if suhosin was creating problems for some users why not simply
> ship the configuration of php.ini with "suhosin.simulation = On" by default?
> 
> 
> http://myeasylinux.wordpress.com/2010/10/25/disable-suhosin/
> 
> 
> This would effectively disable suhosin patch (so no more users would
> complain about suhosin breaking their applications) meanwhile this still
> would allow the rest of users that are worried about security to enable
> suhosin by just changing one line in the configuration.
> 
> Or I am missing something?

Yeah! Working very hard on maintaining the suhosin patch, and then
disabling it by default, don't you think that's a waste of time?

Yet, this doesn't solve the main issue: man power, and will to maintain
it in Debian. Would you like to work on it?

Cheers,

Thomas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657698: Meetoo, make suhosin patch on php5 enabled by default or make it as easy as possible to install

[Jesse Molina]

Just doing a meetoo here and saying that the removal of the suhosin 
patch on php5 is not a good thing for me, though I now understand why it 
was removed, thanks to this bug filing.  I was thrilled when it was 
included by default the first time around.


thanks

--
# Jesse Molina
# Mail = je...@opendreams.net
# Page = page-je...@opendreams.net
# Cell = 1.602.323.7608
# Web  = http://www.opendreams.net/jesse/





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org