Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72477
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8Mpn=dhpKEM_fU=zq0JRx9G0mrD_E6duAu=Sz-6++Qt-TO_g@mail.gmail.com>
References: <CAH8Mpn=dhpKEM_fU=zq0JRx9G0mrD_E6duAu=Sz-6++Qt-TO_g@mail.gmail.com>
Date: Tue, 11 Feb 2014 21:27:00 +0000
Message-ID: <CAPg3XxJXmDGdT+UHrD0=7gvYRUdXDuhvHyAJx4ri2Qp2RPU7Yw@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0129557e484f5604f228206e
Subject: Re: [PHP-DEV] [VOTE] Improved TLS Defaults RFC
From: petercowburn@gmail.com (Peter Cowburn)

--089e0129557e484f5604f228206e
Content-Type: text/plain; charset=ISO-8859-1

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.

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.



>
> Thanks for your time and have a nice day!
>

Thanks so much for your time in getting this together. As I started off by
saying, I'm looking forward to these changing being introduced.

[1] http://markmail.org/message/x46g74zaphdsf5jg

--089e0129557e484f5604f228206e--