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 .
> 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
> 3. Stefan's relationships with PHP upstream (and vice versa) 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
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
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