Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72482
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPg3XxJXmDGdT+UHrD0=7gvYRUdXDuhvHyAJx4ri2Qp2RPU7Yw@mail.gmail.com>
References: <CAH8Mpn=dhpKEM_fU=zq0JRx9G0mrD_E6duAu=Sz-6++Qt-TO_g@mail.gmail.com>
	<CAPg3XxJXmDGdT+UHrD0=7gvYRUdXDuhvHyAJx4ri2Qp2RPU7Yw@mail.gmail.com>
Date: Tue, 11 Feb 2014 17:01:43 -0500
Message-ID: <CAH8MpnmRfSEew7S2ggVPubQYVW8Z_NSv0ZMs9TV=Yq06ATgCCA@mail.gmail.com>
To: Peter Cowburn <petercowburn@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10caa5033c0c04f2289a0b
Subject: Re: [PHP-DEV] [VOTE] Improved TLS Defaults RFC
From: rdlowrey@gmail.com (Daniel Lowrey)

--047d7b10caa5033c0c04f2289a0b
Content-Type: text/plain; charset=ISO-8859-1

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."

--047d7b10caa5033c0c04f2289a0b--