Re: [VOTE] Improved TLS Defaults RFC

From: Date: Tue, 11 Feb 2014 22:01:43 +0000
Subject: Re: [VOTE] Improved TLS Defaults RFC
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Tue, Feb 11, 2014 at 4:27 PM, Peter Cowburn <[email protected]>wrote:

>
>
>
> On 11 February 2014 20:08, Daniel Lowrey <[email protected]> wrote:
>
>> Voting is now open for the Improved TLS Defaults RFC and will run through
>> Wednesday Feb. 19:
>>
>> https://wiki.php.net/rfc/improved-tls-defaults#vote
>>
>> Note that while the implementation is vote-ready at this time (and
>> includes
>> several .phpt files) I'll continue adding more tests in the coming days.
>> If
>> you have questions that you feel have not been addressed during the past
>> two weeks please feel free to ask.
>>
>
> Overall, I would be very happy to see these changes sooner rather than
> later. That said, there is a *super* minor thing that could do with being
> sorted one way or another.
>
> Deprecation of "tls://". Please can I raise a dissenting voice just for
> that particular transport; it currently serves its purpose very well (I can
> has TLS, kthxbye) and asking us to change code to use "ssl://" and add some
> extra context configuration to get the same result seems a little out
> there.  This particular change was not discussed in the other thread, in
> point of fact it read to me like "tls://" would not be deprecated [1]. What
> changed? In summary: I'd really rather "tls://" not issue an E_DEPRECATED.
>
>
I agree, this one is an oversight on my part. The tls:// wrapper "just
makes sense" and deprecating it will likely result in little more than
annoyance. I am going to remove the E_DEPRECATED in these cases.

Oh, another super minor thing; could you make it 100% clear (I *may* be the
> only one not crystal clear!) about how this RFC affects changes that have
> previously been pushed to 5.6 that you wish to undo, and not undo.
>
>
Certainly, sorry for not making it clear in the RFC. The only changes that
have previously been merged for 5.6 that will be rolled-back are the
following stream wrappers:

- tlsv1.1://
- tlsv1.2://

I originally submitted these new wrappers, so hopefully I'm not hurting
anyone's feelings by shuttering them before they ever make it to a release
:)

Going forward the primary tls:// wrapper can be translated as "TLSv1,
TLSv1.1 or TLSv1.2." If code needs to use one of the version-specific TLS
protocols they can specify the relevant constant in the "crypto_method"
context option. Prior to 5.6 the tls:// wrapper translated to "only
TLSv1.0."


Thread (16 messages)

« previous php.internals (#72482) next »