News for hackers. Stuff that matters.
Re:The end of an era: Saying goodbye to search.cpan.org by lkrubner on Tuesday May 22, 2018 @04:27PM (#17129131)
How many PHP websites still work, if they have been in unmaintained since 2005? Can you imagine how many bugs you can find in a 2005 WordPress site? Or PHPNuke?
Re:The end of an era: Saying goodbye to search.cpan.org by kbenson on Tuesday May 22, 2018 @04:59PM (#17129361)
Given CPAN started in 1999, you'd be talking about a PHP 4 project that was mostly finalized by 2005 (at which time PHP 5 had been out for around a year or so). You'd be insane to allow any level of external access to something running on PHP 4 without an insane level of isolation and hardening (and even it would still be a PITA to deal with in an ongoing basis).

For the most part you can take any Perl 5 code written in the last 20 years and just swap out the interpreter for a new one, and your code will run more secure, more stably, and faster (the list of actual deprecations that require change is generally.very small, if anything). It's a double edged sword though, as that back-compat legacy is not easily discounted when a change is proposed that would make modern Perl better but break older Perl. It's one of the reason the language is slower to adopt features than many others.

Re:The end of an era: Saying goodbye to search.cpan.org by ahofmann on Tuesday May 22, 2018 @05:11PM (#17129442)
There is a german Provider (df.eu) with php4 to php 7.2 support. As a customer you can choose which version you want to use. I don't know why they still support down to version 4 but I never had a problem with their products.
Re:The end of an era: Saying goodbye to search.cpan.org by kbenson on Tuesday May 22, 2018 @05:21PM (#17129513)
I would be very leery of trusting that PHP 4 was adequately patched (given the last PHP 4 versions was EOL almost a decade ago), for a number of reasons that don't just include df.eu's technical capability. It's just a much less likely to be looked at system, but that doesn't mean it's not rife with lots of exploits that newer techniques could quickly find, and I imagine that hosting company is generally just patching obvious and reported exploits in PHP 4 (hopefully!). Best case scenario there's an active fork of PHP 4 that some company is monetizing support for (which doesn't negate all the problems I mentioned, but helps a few).

I imagine it's a meeting of groups that need to have some old PHP 4 app running, and a company willing to throw it on a VM and put a best effort into keeping it from becoming a script-kiddie cesspool. It's probably not even as bad as I make it sound as long as you don't need public access. Still, not a business I would want to be in...