Hi Sara, > -----Original Message----- > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara > Golemon > Sent: Monday, July 3, 2017 7:22 PM > To: Anatol Belski <weltl...@outlook.de> > Cc: Niklas Keller <m...@kelunik.com>; Jakub Zelenka <bu...@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > On Mon, Jul 3, 2017 at 12:49 PM, Anatol Belski <weltl...@outlook.de> wrote: > > About how to proceed - I'd say the issue is clear and either way > > should be fixed. The RFC chooses the explicit strength approach. > > What I'm a bit concerned about is, that there's no implementation by > > this time, neither for 7.2 nor for lower. Given there are indeed just > > last moments before the feature freeze, for 7.2 it depends on RMs. > > > I've told Niklas on Twitter, but I'll repeat here for the record. I fully > expect a > rush of last-minute RFCs "urgently" needing an extension of the feature freeze > deadline. These come every new release as people are shocked to discover that > timetables exist. > With issues like this - d'accord. The early pre-release seems to be traditionally a peak time.
> IMO any RFC which does not have a merged implementation by July 20th* > should assume it's not making it into 7.2, however RFCs will be taken on a > case- > by-case basis while in the beta period. As to this one: It certainly seems > important that we don't let users blindly ignore terrible certificates. > That's a > false sense of security, and is arguably worse than no security at all. > > I expect to allow this RFC as far out as beta2 ASSUMING the implementation is > sensible enough to get a passing vote from internals. > > If it moves things along smoother/quicker, I would suggest to constrain this > discussion as though it were ONLY targeting 7.2, and we can have a separate > discussion about how/when it should be back-ported to 7.1 and 7.0 since this > change does represent a (theoretical**) BC break. > IMO for better compatibility, both "new" and "backport" should be seen together. It's clear a fix should come ASAP, but I'd see no reason to rush without a good consideration. That's why I was asking right about the code, as that's the most essential part. It is true, that some breaches are even allowed for security reasons, as per Ferenc, so we need to evaluate it by the matters of fact. Thanks Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
