> > 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. > In further - of course, blocking anything by default can be a vote option, > no question. Say like by the context option, always go by the 7.2 variant. > However I'd see a little sense to disabling sha1 and md5 signed certs > completely. There still can be users, that trust their self-signed > certificates and that can work indefinitely, whether it is good or not. The signature scheme won't be checked on trusted certificates, because it doesn't have an impact there. Trusted certificates are trusted by the public key in the trust store, not by the signature of a certificate. > This especially can concern older systems and organizations perhaps having > intranet apps. In case of a complete ban, another issue would be - there's > no choice other than to stay by an outdated PHP version without any chance > to upgrade, except manually patching it. This is something that should not > happen within a stable release line that supports older systems. See for > example this link https://social.technet.microsoft.com/wiki/contents/ > articles/32288.windows-enforcement-of-sha1-certificates.aspx . > Regards, Niklas
