I'll accept this as a delayed *bump* of my last post on the topic. ;)
> 1. Disable peer-verification by default in windows builds. Personally, I
> don't see this as a valid option as it's terrifically insecure. I believe
> it's better to fail with a warning than allow users to believe they're
> conducting safe transfers when they're 100% vulnerable to Man-in-the-Middle
> attacks.
We can't have Windows swallowing the error while other OSes do not.
Remember that not only do we have Windows production servers, but also
people developing against local Windows installs but rolling out to
other OSes.
Also, the change applies not just to CAs in the public bundle but to
private CAs that will now need to be manually trusted (on all OSes).
You want to flag this problem as early as possible in development.
I don't consider any lowered security restrictions on a Windows build
(of the same PHP version) acceptable. That would be akin to
prescribing PHP-Windows for "toy use only."
> 2. Do nothing and document heavily. Peer verification failures will already
> generate an informative error message. Beyond this, the steps required by a
> windows user to make peer verification work by default are extremely simple:
> - Download this file: http://curl.haxx.se/ca/cacert.pem (or equivalent)
> - openssl.cafile = C:/path/to/cacert.pem (in php.ini)
> Also, we could easily generate a painfully explicit E_WARNING in windows
> explaining exactly how to fix the problem in the absence of the requisite
> configuration.
If [2] is necesssary, then we should accept the burden of being as
verbose as possible.
> 3. Include the same PEM-formatted CA file curl distributes with windows PHP
> binaries and pre-populate the relevant php.ini directive. I don't *think*
> this would come with any licensing issues as the curl cacert file is
> licensed under the same licenses as the Mozilla source file it draws from
> (MPL 1.1, GPL v2.0 or LGPL 2.1). However, I'm not an expert in these
> matters, so others would likely need to comment.
I have no idea about the licensing burdens, but [3] is vastly
preferred if available. Encumbering Windows users with manual
configuration when WPI is supposed to be a package managaer.
Another related possibility (if it eases licensing worries somehow) is
having a separate WPI package for "PHP CA Bundle" -- so it can be
maintained + licensed + removed separately. I know you can make one
WPI depend on another (like with the Windows Role/Feature manager et
al.).
-- Sandy