Re: PHPv4 EoL

[Greg Troxel <gdt%ir.bbn.com@localhost>]

Geert Hendrickx <ghen%telenet.be@localhost> writes:

> On Thu, Dec 06, 2007 at 08:32:58PM +0100, Joerg Sonnenberger wrote:
>> On Thu, Dec 06, 2007 at 09:42:30AM -0500, Greg Troxel wrote:
>> >   the user community would be better served if it were removed than it
>> >   stayed, modulo the effort of maintaining it*
>> > 
>> > * and the effort is pretty low once upstream stops patching, and
>> >   especially if we don't add vulnerabilities if it's eol
>> 
>> So you just leave people with vulnerable installations? Bad idea in my
>> opinion.

People should know that php4 is unsupported, and audit-packages will
show eol.  If it's installed, which is the most likely case of interest,
then people's php4 code will stay installed until they deinstall it,
whether it's part of pkgsrc still or not.  Trying to build it will give
a warning, and can be overridden, the same as any other 'vulnerable'
software.  If we withdraw it, people can still install it - they just
have to work harder.

> Leave them with a clearly marked-as-vulnerable installation, that's a very
> different thing.
>
> We must give people the time to migrate their home-grown or 3rd party web
> applications, which can be very non-trivial in many cases.  Not everyone
> can afford to run the latest-and-greatest software at all times.
>
> Marking php4 as "eol" should be sufficient to encourage people to upgrade,
> and as mentioned, the maintenance effort for us (pkgsrc) is minimal.
>
> Heck, we only just removed BIND 4 from pkgsrc as well..

Agreed.

> By the way, PHP.net said they will continue to provide critical security
> fixes until August 8, 2008.

If they are providing "critical security fixes", that's almost not EOL,
but I suppose it would have to be "security fixes" to be ok.

Again, the question is: is a person with php4 installed better served by
being able to manage that within pkgsrc or not, given that pkgsrc will
tell them via audit-packages, binary package placement in vulnerable/,
and a failure at build time, that the package has issues?  If someone
chooses to accept the issues, there is still value in automated package
management, and I think it's unreasonable of us to decide for other
people what they should not do.  To warn them is fair, though, but no
one's arguing about that.