Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71903
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaKiKzQvEpb-8Y0YtXip4TGwNXsErkwEgOrocyP7WHa8w@mail.gmail.com>
References: <CAH8MpnmVnYiw7nJ11v+h=31+p+HBopBjJ80afpZkW-bW1LJb2A@mail.gmail.com>
	<CALwr1GnCqXZUk5zDfmtBa8cqmZS9qiGxVtc0JAbpShsJPodhtw@mail.gmail.com>
	<CAH8Mpn=1OMhKjMPAFGQ6hF309zFN4=ZFMZc06ZQvT8S2vX4hJw@mail.gmail.com>
	<824758DB-57D8-4B4B-BECD-E1F12531FDE0@rouvenwessling.de>
	<CAH8Mpn=3D7bSWQicgaRPKBtriqkk08p8Jh0+ud6N8BEbJXAu7w@mail.gmail.com>
	<CAGa2bXaKiKzQvEpb-8Y0YtXip4TGwNXsErkwEgOrocyP7WHa8w@mail.gmail.com>
Date: Fri, 31 Jan 2014 17:08:26 -0500
Message-ID: <CAH8MpnnRYCd3dX=7Y7C63TqNGCh2gRVsodctiRrjJkvNS7Zb1g@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: =?ISO-8859-1?Q?Rouven_We=DFling?= <me@rouvenwessling.de>, 
	=?ISO-8859-1?Q?P=E1draic_Brady?= <padraic.brady@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134db86cd6eed04f14b699a
Subject: Re: [PHP-DEV] Improved TLS Defaults
From: rdlowrey@gmail.com (Daniel Lowrey)

--001a1134db86cd6eed04f14b699a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 31, 2014 at 4:47 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Daniel,
>
> On Fri, Jan 31, 2014 at 2:17 AM, Daniel Lowrey <rdlowrey@gmail.com> wrote=
:
>
>> On Thu, Jan 30, 2014 at 12:11 PM, Rouven We=DFling <me@rouvenwessling.de
>> >wrote:
>>
>> >
>> > On 30.01.2014, at 04:15, Daniel Lowrey <rdlowrey@gmail.com> wrote:
>> >
>> >  As I mentioned in the updated RFC
>> > text I think it makes sense to deprecate the specific wrappers in 5.6
>> and
>> > look to remove them in 5.7 as they're really unnecessary in light of t=
he
>> > ability to specify flags for the specific individual protocols you wis=
h
>> to
>> > use on a given stream.
>> >
>> >
>> > Please don't. By deprecating in 5.6 and removing in 5.7 (which would b=
e
>> > faster than anything before) you'd royally screw everyone skipping a
>> > version - something that gets increasingly likely with the faster
>> release
>> > cycle.
>> >
>> > I'd suggest deprecating them now with this RFC and remove it in PHP 6,
>> if
>> > PHP6 doesn't come around they could still be removed in a future RFC.
>> >
>> > Best regards
>> > Rouven
>> >
>>
>> Sounds good to me. Will update the RFC for deprecation of the sslv2:// a=
nd
>> sslv3:// stream wrappers in 5.6 with removal planned for PHP 6.
>>
>
> I agree that obsolete protocol should be deprecated.
> However, removal is totally different. I would like to have *long* period
> before
> removing any feature from PHP whenever it is possible. It could be used a=
s
> toy
> for security experiments as well as for incredibly old internal servers
> never updated.
>  Perhaps, remove them for PHP 7 or even 8?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

I'm perfectly fine with a long period for removal. However I don't see any
reason to persist deprecated features into a PHP 6 version because all the
existing functionality is retained. I'm only deprecating the potentially
confusing protocol-specific stream wrappers -- not the ability to use the
old protocols. Even when the deprecated wrappers are removed the old
protocols will still be available.

I understand that it's a bit difficult to see the difference in the current
RFC version because I haven't added code examples yet. However, I finished
the implementation patch with tests today and will update the RFC either
this evening or tomorrow with a fully mature proposal. I've taken into
account everything that has been discussed to this point and am pleased
with the resulting solution (I think everyone else will be as well). I'll
mail the list when the "final" (subject to input) RFC is live on the wiki
and we can revisit the conversation if necessary.

As always, the input is greatly appreciated!

--001a1134db86cd6eed04f14b699a--