> 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.