[php-maint] Bug#658208: Bug#658208: Bug#658208: Bug#658208: Bug#658208: [php5] README.Debian.security: "problems used by sloppy developers"

Filipus Klutiero chealer at gmail.com
Wed Feb 8 17:03:50 UTC 2012

On 2012-02-08 02:21, Thijs Kinkhorst wrote:
> On Tue, February 7, 2012 18:51, Filipus Klutiero wrote:
>> On 2012-02-03 07:16, Thijs Kinkhorst wrote:
>>> On Thu, February 2, 2012 19:42, Filipus Klutiero wrote:
>>>> Hi Thomas,
>>>> On 2012-02-02 13:18, Thomas Goirand wrote:
>>>>> On 02/03/2012 01:50 AM, Filipus Klutiero wrote:
>>>>>> That would leave the question, where is PHP functionality flawed if
>>>>>> it
>>>>>> is not in PHP's design?
>>>>> That's a discussion that could be huge. Do you think that
>>>>> README.Debian.security or even the Debian BTS, are places were we
>>>>> should
>>>>> discuss this? (or maybe you're not having this discussion, and regret
>>>>> that the README.Debian.security leads to it?)
>>>> Sorry, there seems to be a misunderstanding. What I'm reporting is that
>>>> the current README contains a non-sensical item. Thijs has fixed the
>>>> problem, but the new version is also problematic. The new version would
>>>> say:
>>>>> Security support will not be provided for flaws in functionality which
>>>>> is not flawed in the design of PHP but can be problematic when used by
>>>>> sloppy developers.
>>>> I also suggested in
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639230#25 that the
>>>> entire item be scrapped.
>>> It's there because people report(ed) on security mailinglists, and CVE
>>> names got assigned for, such issues. We want to make it clear that we
>>> categorically do not treat those as vulnerabilities.
>> Could you please give examples, so we're all clear on the kind of
>> problem we're talking about?
>>>> What I am saying is that this wording will leave the reader puzzled; if
>>>> a flaw in a PHP functionality is not in PHP's design, the reader will
>>>> wonder where the flaw is.
>>> In our view point the flaw is in sloppy application code. The part 'but
>>> can be problematic when used by sloppy developers' indicates that to the
>>> user.
>>> I've changed 'developers' to 'application developers' to make it clear
>>> that we're not referring to PHP upstream development here.
>> Fine, but that leaves the question equally unanswered.
>> If a flaw in PHP functionality is not in PHP's design, where is the
>> flaw? A flaw in PHP functionality is not in application code, sloppy or
>> not. PHP functionality exists independent of application code using it.
> I do not agree that the question is unanswered. Example: The perceived
> flaw is that someone claims on a sec mailinglist that untarring a tarball
> which has ..-style paths using PHP's tar functions allows one to untar
> files outside of the working directory, and according to them PHP should
> prevent this. This flaw then gets a CVE name assigned. We on the other
> hand are at the position that such a thing is not a flaw in PHP's design
> but in the application code that is written sloppily not to check what
> it's extracting. The anwser to your question is therefore: the flaw is in
> the application code.
> We provide some examples to illustrate that: putting untrusted data into
> tar or unserialize functions without further checking may result in
> adverse effects.

I see. Could you please provide example CVEs, or the names of the 
specific relevant tar functions?

More information about the pkg-php-maint mailing list