On 12/17/2013 12:08 PM, Daniel Lowrey wrote:
given that this is a security related change, one could argue that
security
fixes should be ok to go in a minor version, even if they break BC.
This was my thought process. In my mind the RFC is about improving security
for users who don't know any better. I'm hoping to avoid the "Are we
allowed to break BC?" discussion.
Adding a CA file to the distribution is exceedingly simple, but this is not
a silver bullet. For example, the Mozilla CA file used by cURL is usually
updated three or four times a year. Even when bundling a CA file it would
only be a matter of time before a distribution's version was out of date.
In the end we can only do so much before users must bear the weight of
maintaining an acceptable level of security themselves.
So then bundle it, doing something is much better than doing nothing, there are plenty of opportunities to update the cafile with minor versions, the package maintainers will likely solve the stale cafile problem for us on the major distributions, when they see we are actually doing something about it ...
It really does not seem sensible to purposefully break compatibility when it can be retained easily, the vote is going to be split with no clear outcome doing no good for anyone. Reduce the options to two if you want to actually move forward.
That's enough from me, gonna go find something to break :)
On Tue, Dec 17, 2013 at 5:58 AM, Ferenc Kovacs <
[email protected]> wrote:
On Tue, Dec 17, 2013 at 9:01 AM, Joe Watkins <
[email protected]> wrote:
On 12/17/2013 02:03 AM, Daniel Lowrey wrote:
Thanks for the input -- I'm just happy people are interested in the
issue!
Let me address a couple of things ...
you get essentially a configuration that can not use https at all
I wouldn't say this is the really the case. Users still have access to
the
same https functionality they've always had. The only difference is that
they now must explicitly acknowledge that, "Yes, what I'm doing is
insecure. I'm aware of it and I choose to continue anyway by specifying
this context option."
But it may be against the spirit of the RFC?
:) Yes ... that's kind of what I'm going for. Basically it's my thought
that many (most?) people using things like file_get_contents('
https://')
are completely unaware of this issue in the first place. My thinking here
is that instead of not saying anything and just giving these users a
false
sense of security we should at least make mention of the problem instead
of
sweeping it under the rug.
people would still ignore it
Almost certainly. In fact, users do this routinely with curl_* because
they
don't know any better.
Finally, I think this problem can largely be alleviated with appropriate
documentation. Should the RFC pass I'll work to make sure that any peer
verification changes are *well-documented* to (hopefully) stem the
inevitable storm of bug reports.
On Mon, Dec 16, 2013 at 8:42 PM, Stas Malyshev <
[email protected]
wrote:
Hi!
Please throw your votes at the TLS Peer Verification proposal:
I'm not sure what to vote for here, because I like the ideas in the
patch about having a setting for CAfile, which in many distros would by
default enable peer verification and thus make you more secure, but I
don't like the fact that when you compile PHP, you get essentially a
configuration that can not use https at all, since you have no CA file
configured.
I'd like it more if there was an option where if you set cafile or
capath, you get automatic peer verification, but if you don't, you do
not have it. But it may be against the spirit of the RFC?
I know you propose a warning in this case, but judging from the story of
the datetime timezone warning, people would still ignore it. Also
warning is not much help if for some reason you don't know where to get
a cert file. And there's no way to disable peer verification on ini
level.
--
Stanislav Malyshev, Software Architect
SugarCRM:
http://www.sugarcrm.com/
(408)454-6900 ext. 227
Morning Internalz,
Daniel, you have to assume that nobody will even read the manual;
because they will not. I'm up for making it safer, but not for breaking
anything at all in a minor version, if we do not bundle the CA file it
would appear to break a bunch of requests that previously worked, that
doesn't seem good enough to me.
We can change the behaviour of the engine, but we cannot change
the behaviour of users code; if a requests works now, regardless of it's
security, it must continue to work with the default settings, therefore, I
suggest that you remove the option to change the behaviour of the engine
without maintaining the behaviour of users code, if the aim is to make
these requests more secure by default, then allowing it to fail, by any
means, defeats the object of making any changes at all.
If I'm wrong, tell me how :)
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
http://www.php.net/unsub.php
I'm not taking sides, but given that this is a security related change,
one could argue that security fixes should be ok to go in a minor version,
even if they break BC.
--
Ferenc Kovács
@Tyr43l -
http://tyrael.hu