On Fri, Jul 05, 2024 at 02:37:41PM +0200, Clemens Lang wrote: > Hi, > > > On 5. Jul 2024, at 12:38, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > 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. > > Please start addressing this with whoever maintains the TPM specification. The TPM spec is maintained by the Trusted Computing Group, and I have no influence there. > SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this > change is already broken in FIPS mode, and the deprecation of SHA-1 will > only continue to cause more and more problems. swtpm works around that be unconditionally disabling FIPS mode in openssl already. This is fine, because the guest OS can put itself in FIPS mode, which will prevent it from using the undesirable algorithms, even if the TPM exposes them. > > 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. > > An alternative is to run swtpm with OPENSSL_CONF in the environment > pointing to an alternative openssl configuration file that re-enables > SHA-1. You could maintain this configuration file together with swtpm. Can custom openssl config files "inherit" from the primary one. ie can we have a config file that just references the primary, while toggling only the sha1 setting, so we're not overriding all the openssl config settings ? > > 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. > > The upstream work on this is stalled, both due to my lack of time > and upstream’s requests to change it fundamentally twice after I > had working implementations. I wouldn’t rely on this showing up > any time soon. I still want to eventually finish it, but until > that happens and then gets released in a new OpenSSL version, > this doesn’t exist. > > > > Until that exists, however, I'm inclined > > to just set OPENSSL_ENABLE_SHA1_SIGNATURES in swtpm startup, > > despite the warnings not to do this. > > As announced, we’re going to break that without regard for whether you used it, and it won’t make a difference in FIPS mode. > You should really use a separate openssl configuration file using OPENSSL_CONF instead, and start a discussion to get the TPM standard updated. 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
