On Fri, 2016-08-19 at 09:01 -0400, Stephen Gallagher wrote: > > I'm having a hard time following the argument of scale and risk here > > when it pertains to schedule slip. The package itself is fairly > > self-contained and isn't likely to cause issues against the actual > > Alpha test criteria. Can you elaborate why you think doing this as an > > FE would cause a slip? > > > > Essentially, it means that anything in Fedora using 1024 RSA root CAs would > suddenly fail. It's not as simple as that. The suggested change doesn't mean that our software will block any CAs with 1024 bit. I've explained the technical background in detail in the link to the openssl ticket that can be found in my initial message of this thread. The issue here is that whenever a server certificate needs to be verified, there may be more than one potential chain of certificates to find a trusted root CA. The CA organizations had planned to phase out their roots, and had implemented mitigations already, when this project started two years ago. In order to still work, software must be able to find alternative chains of trust, to the newer replacement root CAs, which we already ship in our CA list. Two years ago, OpenSSL and GnuTLS and glib-networking weren't able to find these alternative trust chains, which was the only reason why we had decided to keep trusting the old root CAs. Meanwhile our software has been fixed, and those library now can find the required alternative trust chains, and things work. > I don't have a clear picture of what exact tests are run, but I'd > not be surprised to discover some of the Workstation browser tests to suddenly > start failing as a result of this. That's not even including anyone who just > starts poking around with it and filing bugs because their favorite website is > no longer available. Based on the work we've done, I don't think this will happen. Our group has scanned a very large number of the most popular sites (Alexa). We identified that there are still a very small number of sites that still use the legacy configuration that was problematic with the older software versions, but couldn't find issues with the SSL/TLS libraries I mentioned. We have been preparing this, and have waited for quite a bit of time, before this is now being suggested as a reasonable thing to do. > Put another way: with my Blocker/FE reviewer hat on, I'd be inclined to vote > this as too risky to grant an FE to, simply because we have no real way of > knowing what it would break. I'd rather not jeopardize the already-slipped > alpha for a late change with an unknown risk level. It won't break software that uses NSS / OpenSSl / GnuTLS / glib-networking. Sites that are trusted in a fresh Firefox profile will work with these other software libraries, too. Only sites that aren't trusted by Firefox might fail to be verified, but that's exactly what we want to achieve, for security reasons, following the trust decisions that have been made by the Mozilla CA maintainers, and which we want to follow. > With my FESCo hat on, I'd be in favor of landing this in updates-testing > immediately. Then folks who install the Alpha will get it in their first > update > and we'd have ample time to work out the issues prior to Beta. If we agree to try to include it with Fedora 25, then both before Alpha and after Alpha are fine with me. Thanks Kai -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
