On Thu, 6 Oct 2016, at 11:41 AM, Lester Caine wrote: > It is already an established component in PHP and while it's use has > been discouraged for a long time, simply switching it off will break a > lot of legacy applications.
How many applications that are not following standard security guidelines are not following basic security principles? It doesn't matter if it's an established component, a vulnerability is a vulnerability. BC shouldn't matter; especially for those who are not willing to patch their applications to use the latest information we have available to us. You either keep up with changes; or you don't. New majors, and even minors (if we're ignoring semantic versioning) should be able to change something, it should be up to the maintainers of an application to decide whether it's time to upgrade or not, internals shouldn't manage that for you. If you're using Composer, you can lock your dependencies to prevent your application from breaking. If you're up to date with the latest information, you can choose to evolve. Mcrypt, now (I think) belongs in PECL, I will be looking at (a major) code repository over the next few weeks and looking to provide a simple upgrade path. DM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
