Morning, guys, > -----Original Message----- > From: Niklas Keller [mailto:m...@kelunik.com] > Sent: Wednesday, July 5, 2017 4:39 PM > To: Anatol Belski <weltl...@outlook.de> > Cc: Sara Golemon <poll...@php.net>; Jakub Zelenka <bu...@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > Ok, so you strive to create a completely new RFC with a solution based > on today's situation. I think you still don't see my point. Say there's > insecure_allow_sha1_signature, which is a stream context. Then > > > - in 7.0 and 7.1 > - if absent, insecure_allow_sha1_signature = true > - if present, the given value taken > - impact for 7.2 migration - if explicit > insecure_allow_sha1_signature = > false is in the code, no impact > - in 7.2 > - if absent, insecure_allow_sha1_signature = false > - if present, depending on the decision either the exact value is > taken > or ignored > - future impact - none, the option can be even silently removed > - in 7.3 > - removed and disabled completely > > No see same if insecure_allow_sha1_signature is an INI > > - in 7.0 and 7.1 > - if not set, insecure_allow_sha1_signature = On > - if set, the given value is taken > - impact for 7.2 migration - depending on decision, either it's > deprecated warning or disabled by default > - in 7.2 > - if not set, insecure_allow_sha1_signature = Off > - if set, the given value is taken, warning is issued > - in 7.3 > - removed and disabled completely > > Both options do same, but in different manner. Both have advantages > and downsides, but one option only is both necessary and sufficient to achieve > the goal. > > > > You plan assumes we'll disallow sha1 / md5 completely in the future, dunno > whether that'll be the case. I'd prefer that. > Nome, that's not mine, it's was your intention as I've remembered, might be wrong. Anyway, what I wanted is only to show the redundancy having multiple ways to do same.
Anyway, now that Jakub also responded with an approach as well, maybe it's time to get an RFC get the thing done? It could have the two suggestions brought till now as an "exclusive or" choice and the disablement plan. The one that won would be followed up. An implementation were great to have before. Both suggestions, either the separate context options for md5 and sha1, or security levels, do same job and only differ in the way it's done. The downside of security levels is, that fe the suggested security level 2 will disable both, while user might want to disable only sha1, that's where the separate options win on flexibility. Whereby having a higher security level should automatically ensure a certain weak functionality is disabled at once, which has some use as well. IMO, the INI option is a no go - the argument that user can get everything done at once breaks encapsulation, as not every stream in the app might require it. The plan about the default disablement by version brought by Jakub sounds plausible, as for me. IMHO the complete disablement should not be a part of this RFC. I would suggest, it's time to get on RFC and bust this issue. It would be great, if all the interested parties could cooperate on this. Thanks Anatol
