[pkg-php-pear] (Not) shipping tests in binary packages

[Mathieu Parent]

2013/7/11 Olivier Berger <olivier.berger at it-sudparis.eu>:
> Hi.
>
> Thomas Goirand <zigo at debian.org> writes:
>
>> On 07/03/2013 05:08 AM, David Prévot wrote:
>>> Hi,
>>>
>>> Le 02/07/2013 15:47, Mathieu Parent a écrit :
>>>> 2013/7/2 David Prévot <taffit at debian.org>:
>>>
>>>> I still consider having tests as part of packaging a good practice,
>>>> but it should be done in a different path and this path should not be
>>>> available from the web server (i.e, not in a Apache <DIrectory>).
>>>
>>> Even then, there is still a risk of a misconfigured web server (that can
>>> also happen to be a default value).
>>>
>>>      http://www.debian.org/security/2012/dsa-2452
>>
>> Come on, that one is *not* an argument... :)
>>
>> I do think that tests are very valuable for our users. They, by
>> definition, include good examples on how to use a lib.
>>
>>> Introducing (or even
>>> keeping) potential risk vectors that are not mandatory at runtime
>>> doesn’t seems like a good idea at all: they end up in production servers…
>>
>> IMO, they should just be shipped in /usr/share/doc, and that's it.
>> Probably that's a very good idea to fix pkg-php-tools to do that, and
>> probably to *not* do a symlink in /usr/share/php.
>>
>
> I think that tests should not be shipped. Maybe in a companion -dev
> package if really needed.
>
> It's not obvious our users will need to learn how to use the
> libs... they may just be running apps depending on them, period.

Yes. But when they file a bug, we can simply ask them to run the tests
(without apt-get source). Or even, automatically run those tests.

> So, maybe a more interesting approach would be to suggest good
> documentation/example snippets for upstream to add to their docs, or add
> some ourselves, maybe copied out of some of the tests, and put them in
> /usr/share/doc/.*/example/ where they'd belong. I guess this would
> probably be more compact than a full test series, and much more
> pedagogical.

Having tests installed by default adds value IMO. And I don't really
see the risks unless when the test are directly accessible from the
network (i.e in a vhost document root or alias or ...), which is the
security hole to fix. Another risk is when the php app can do
arbitraty includes (which is a BIG security risk - think of
include('/etc/passwd');). Another thing is that PHP by default
installs tests in "test_dir" (currently /usr/share/php/test in
Debian). I'm OK to change this path, but I'm not sure of the gain.



Regards

--
Mathieu Parent