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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature