On Tue, Dec 17, 2013 at 12:27 PM, Joe Watkins <krakjoe@php.net> wrote:
> On 12/17/2013 10:58 AM, Ferenc Kovacs wrote:
>
>> On Tue, Dec 17, 2013 at 9:01 AM, Joe Watkins <krakjoe@php.net> 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 <smalyshev@sugarcrm.com
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> Hi!
>>>>
>>>>>
>>>>> Please throw your votes at the TLS Peer Verification proposal:
>>>>>
>>>>>>
>>>>>> https://wiki.php.net/rfc/tls-peer-verification
>>>>>>
>>>>>> Voting closes Dec. 24 ... Happy Holidays!
>>>>>>
>>>>>>
>>>>> 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.
>>
>> Tyrael,
>
> Okay, but there's no good reason not to implement the fix in the
> most backward compatible manner in the first place; breaking BC doesn't
> make it any more secure, it just breaks shit.
> Additionally when you consider the context, this is not affecting
> the behaviour of some rarely used functionality, it would be reckless to
> change it's behaviour when retaining compatibly is no problem at all.
>
> Cheers
> Joe
>
Hi Joe,
As I mentioned, I'm not saying that we should accept the proposal, I only
replied because you stated that
"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."
Ofc. I also would prefer if we could improve the situation without
introducing a BC break in a minor version.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu