--=-7fKEEDzgqBeH1OBu3Nx8

Content-Type: text/plain; charset="UTF-8"

Content-Transfer-Encoding: quoted-printable

Hey.

First, thanks Ond=C5=99ej, for bringing this to a wider audience :)

On Thu, 2012-02-02 at 13:55 +0100, Ond=C5=99ej Sur=C3=BD wrote:

> 1. Suhosin patch has an impact on the speed and memory usage. This has

> been documented and even author admits it [1].

>=20

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

>=20

> #ifdef ENABLE_SLOWER_SUHOSIN_SECURITY

>=20

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

--=-7fKEEDzgqBeH1OBu3Nx8

Content-Type: application/x-pkcs7-signature; name="smime.p7s"

Content-Disposition: attachment; filename="smime.p7s"

Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITMjCCBggw

ggPwoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV

aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5

MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDUxMDE0MDczNjU1WhcNMzMw

MzI4MDczNjU1WjBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5D

QWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MIICIjANBgkqhkiG9w0BAQEF

AAOCAg8AMIICCgKCAgEAq0k1EUh80iZ+U5TPQ6ndKNdCKovzh3gZWHwPntqJfeH763KQDXShlmSr

n6AkmXPa4lV2xxd79QSsRrjDvn9kjRBsJPNhnMDykPpR5vVpAWPDD1biSkLP4kSMJSioxXkJfUa5

ivPp8zQpCEXkHJ/LlAQcgagUs5hlxEPsToKNCdG9qluNktDs3pDFfwrC4+vmMVpedD6XM1nowwM9

YDO/99FvR8TN7mKDUm4uCJqk2RUYkaaFkkewrkjrbbch7IUaaHI1q//wEF3A9JSnatU7kn5MkAV+

k8Esi6SOYnQVcW4LcQPqrxU4mtTSBXJvjPkr61pyJfk5RuNyGz4Ew2QnIhAqik9YpwOtvrQuE+1d

qkjX1X3UKntc+kYEUOTMDkJbjO3b8s/8lpPg2xE2VGI0OI8MYJs7l1Y4rfPSW4ugW+pOlrh819Wg

hnBA05Ept6I8rfWMu88akorkNHvA2Gxf6QrCw6cgmlrfLF1SXLpH1ZvvJChwOCAv1X8pwLJBA2iS

zOCczJdLRe86EAqrcDqYlXCtNbHqhSukHIAhMamuYHqAJkgAuAHAk2NVIpE8Vuev2zol848xVOom

i4FZ+aHRUxHFe50D9nQR4G2xLD8shpGZcZqmd4s0YNEUtCysna+MENOfxGr4bxP8c1n3ZkJ0Horj

+NzSb5icy0eYlUAF++kCAwEAAaOBvzCBvDAPBgNVHRMBAf8EBTADAQH/MF0GCCsGAQUFBwEBBFEw

TzAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuQ0FjZXJ0Lm9yZy8wKAYIKwYBBQUHMAKGHGh0dHA6

Ly93d3cuQ0FjZXJ0Lm9yZy9jYS5jcnQwSgYDVR0gBEMwQTA/BggrBgEEAYGQSjAzMDEGCCsGAQUF

BwIBFiVodHRwOi8vd3d3LkNBY2VydC5vcmcvaW5kZXgucGhwP2lkPTEwMA0GCSqGSIb3DQEBBAUA

A4ICAQB/CIih2hpQSdqJ+6EIcvOK9x7EOrR5WyAwsUXewl3TZWnxwl1UVDyFX7l7QpHCmf0bUZur

RqWhEFOebYisc24sM6bw9J7gdcE+iEWp4WZD/lZa0XpBePdA2ko68QtbpbsWBubC55O5hU2XT7Ee

OEOA75sNjO+4p2AAh1d9HkQcyyPvmzyZna+1KRxFeRaWTSdt8Rxsw8JVZLO8FOLzpB8eMvwnFQXP

3S6uPoJhe/AhEBj2ROpTOfnc0Jog4Ma74LtaT8SZyAe9tb2i2y5iDUI0Qbz/i4r1USKqiDAA4rDU

vL5lutUDV3mb6NzITfhQ7ZGlUiiirPs2WD7plCuRUIcb1l7WjMz3DxAMUk7QFmHl5QpsvxfHckZX

nJj1bGBjem9euU4vyLm5u2qFvJgN7fk+l4Q0lK4Ar6Hl55JuTr3z4tkUi1zS6wFsoBelLRDrnHpK

vb3uzv3tIkCrcDiI9QqHasKrBWDJSAXaU8HeRHdqs/M8PO2AvKY4SikkX/5ZO5slelZjAGS5XaRi

fVc2T62D7x+SU6COd1fd5WERPSMAkEw8+qNgkwSjrzX2DmqPT0pgp4UFbEahj/THduOhWVf3cbLE

bhRcbW1BZt8bk7HUAMPuy888PSGAqV9jZfzd4F+k9CvwhXFB1Gcl+xqxl67WmYITQdJupRuZJ4Dn

C6moADCCBo8wggR3oAMCAQICAwCyHTANBgkqhkiG9w0BAQUFADBUMRQwEgYDVQQKEwtDQWNlcnQg

SW5jLj