On Mon, Jun 10, 2024 at 08:40:22PM +0200, Clemens Lang wrote: > Hi, > > > On 10. Jun 2024, at 20:16, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > > > On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote: > >> I wish this proposal included some examples of what might get broken > >> and what will keep working. I guess I am not the only one who have > >> very vague understanding what is difference between "signatures" and > >> "hashing" or other purposes SHA1 can be used for. > > > > SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and > > to old network equipment and the like will not be possible. > > > > I'm annoyed that this is not just put behind the LEGACY policy, since > > if that's not what "legacy" is for, what _is_ it for? > > I’m pretty sure Alex was planning to keep SHA-1 signatures working in the LEGACY policy, or even DEFAULT:SHA-1 (as it currently is on RHEL 9). > > It isn’t explicitly spelled out in the proposal. What the proposal does say, though, is that you can use FEDORA40 as policy. > > > > As an aside, it'd be very nice if policies could be set per-process. > > That would greatly enhance security by allowing specific programs to > > connect to the legacy machines, while maintaining general system > > security. > > See this text in the proposal (emphasis mine): > > Users that need the previous behaviour and don't mind the security > implications will be able to revert to the old behavior system-wide > (update-crypto-policies --set FEDORA40) or ***per-process (runcp > FEDORA40 command args, requires a copr-packaged tool)***. I've (re-)discovered that this change is going to impact on swtpm that is used with QEMU to provide a virtual TPM to guests. The TPM2 specification has fully crypto agility, however, the sha1 algorithm is one of the few that is declared mandatory to implement. Though it is documented as deprecated by the spec, we need to provide it to be compliant. I don't really want to tell people to change global crypto policies because there is alot of software in the virt host OS stack that uses crypto and should remain protected by the strong default crypto settings. The 'runcp' command is really particularly nice as a solution though. Using that in a non-interactive scenario will require modifying the software that launches swtpm to wrap its execution. Or we have to replace the swtpm binary with a shell script that invokes the real binary indirectly, which isn't especially nice either, as wrapper shell scripts often require then changing the selinux policy to allow their use. The change proposal talks about an API being added to openssl to allow this to be changed programmatically, which is really what I would like to see, so that swtpm can just request SHA1, as this has the lowest impact. Until that exists, however, I'm inclined to just set OPENSSL_ENABLE_SHA1_SIGNATURES in swtpm startup, despite the warnings not to do this. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
