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. > 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. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
