Re: Re: Windows Peer Verification

From: Date: Mon, 03 Feb 2014 22:17:26 +0000
Subject: Re: Re: Windows Peer Verification
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-72144@lists.php.net to get a copy of this message
> ini_set('openssl.cafile', 'C:\omg\this\is\too\hard.pem'); OK, users simply add ini_set on all their pages. Why bother playacting about this being worth discussing if you actually think it's \just\so\easy\for\any\user? Why start this thread? >> Or else they need to change all outbound stream >> code, which in many cases isn't even theirs to safely change. > Then I'm using a garbage library and need to migrate *immediately*. Yay! Let's tell people to "migrate immediately" from a WordPress plugin but also act like we didn't affect their PHP user experience in any way. Not even some negative impact for a net good, nope, all positive impact. I think you need to get more experience with the range of third-party code that doesn't turn on verify_peer. And frankly it is PHP's fault that most code doesn't do so, since PHP was insecure by default and never threw an error in the past. Heaping blame on library authors is absurd. If someone is writing to the Twitter API, they might not know anything about CAs, figuring, not entirely unreasonably, that making an outbound connection to https://api.twitter.com would be as verified as it would be from a browser. Furthermore, even if they did have an inkling that their connections weren't best-practices secureit is ridiculously cumbersome to try to bundle a PEM with a lightweight CMS plugin. > This is the entire point of warnings: to tell you you're doing > something wrong. Suggesting this is somehow harmful is seriously > negligent. Let's not pretend like the doctor setting a cast on a > broken arm is the problem; the broken arm is the problem. Of course it's harmful to spew warnings into a log when you damn well you could have worked harder (i.e. bundling the trusted CA bundle) to not have that happen. -- S.

« previous php.internals (#72144) next »