On Sat, Apr 30, 2022 at 4:28 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote: > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 > > > > > > == Summary == > > > > Cryptographic policies will be tightened in Fedora 38-39, > > SHA-1 signatures will no longer be trusted by default. > > Fedora 37 specifically doesn't come with any change of defaults, > > and this Fedora Change is an advance warning filed for extra visibility. > > Test your setup with FUTURE today and file bugs so you won't get bit > > by Fedora 38-39. > > > > Changes like this have been very disruptive in the past because they > haven't been completely thought through. > > Can we please make 100% sure these policies are not going to break > things like VPN clients in the way that we have before. > > If you want to distrust a server SSL certificate because it's using > SHA1, that's OK. But make the crypto libraries report that just like > any *other* untrusted cert, in a way which allows the application (and > ultimately the user) to decide to accept it this time. > > The blanket refusal we had in previous iterations was awful. > > Likewise for *client* certificates. If the server issues us a > SHA1-based certificate and wants us to authenticate with it, that's the > server's problem. Making in-distro software refuse to use that client > cert just pushes uses back to using proprietary software and is overall > detrimental to our users. > > I understand there has been some progress on fixing the crypto > libraries to get this right, but I'd like FESCo to make those an > absolute condition on any further crypto pedanty in Fedora — those > things *have* to work on a per-application, user-overridable basis No arguing here... > without introducing regressions, or the Feature is reverted. ... but not sure if I understand this bit. Flipping a default and not introducing a regression is only possible if each and every impacted workflow and scenario is caught by one of the proposed testing strategies or something else. As much as I'd love to see that happen I think it's safe to say it's just not gonna happen (hence the next "jump scare" phase + 2 following cycles). _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
