Re: [VOTE] Improved TLS Defaults RFC

On Tue, Feb 11, 2014 at 4:27 PM, Peter Cowburn <petercowburn@gmail.com>wrote: > > > > On 11 February 2014 20:08, Daniel Lowrey <rdlowrey@gmail.com> 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."