On 11/7/2016 3:41 PM, Alice Wonder wrote: > On 11/07/2016 04:29 AM, Nikita Nefedov wrote: >> It might make even more sense to not provide a default here at all. As >> history shows that those methods that are considered secure today can >> become less-than-desirably secure in a couple of years. Which means >> the same cycle of deprecation/changing defaults in years to come. >> > > 100% agree > > One of the problems that OpenSSL had is that it kept too much for > compatability with software that hadn't updated to use more modern more > secure protocols. Hence it supported SSLv3 for forever even long after > it was no longer really needed, supported things like heartbeat enabled > by default even though less than 1% of users had any need for the > extension, etc. > > Keeping things secure means breaking software that doesn't keep up to > date. That's just the way of things. > > I confess it bothers me that mcrypt is only being depricated in 7.1 and > not removed, for example, and that there are plans to continue it as a > PECL module. It's a dead project, dead security projects are not secure. > > Using defaults can be dangerous too, when a system administrator doesn't > have to think about it because the defaults "work" they often don't, > even though the way the defaults "work" is often less than ideal. > > All the dangerous WordPress plugins out there are ample evidence of > that, where they default to executing shell commands so that they "work" > in the event the server doesn't have the right PHP extension available - > or all the php image processing modules using ImageMagick that by > default worked with everything under the sun and thus were vulnerable to > CVE-2016–3714 when they could have (should have) required the admin > specify a whitelist of image types it accepted. > > Anyway that's my viewpoint - screw compatibility when it comes to > security, and don't use defaults that can cause security issues when the > admin chooses not to think about the security implications. > > Hope this isn't just seen as noise, if it is, I apologize. >
I agree and disagree. Security related defaults should be changed without worrying too much about breaking changes if the old approach is really problematic. The automated approach of trying to recover, as proposed, seems like a great idea. Ignore the performance hit completely and remove this fallback in the next minor version where it simply does not work anymore. However, having defaults makes perfect sense. Nobody will invest more time into finding what is more secure just because there is no default. They will use whatever they find first. Additionally it's just shifting of responsibility from the language/library to the developer. If a developer relies on algo-insecure as default value or algo-insecure as self chosen strategy does not change the fact that algo-insecure is used instead of algo-secure. Algo-secure might be the default for the next release of said language/library, however, if that language/library is not updated it will never be used. The same is true for the hard coded algo-insecure from the developer. BUT and this is a huge BUT. It is more likely that the developer updates the language/library than the various usages of the hardcoded algo-insecure everywhere in the code. Code, that he or she has long forgotten! -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
