Hi, > On 25. Feb 2025, at 10:29, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > When a host is in FIPS mode, presumably openssl should already > automatically disable all functionality that isn't FIPS compatible. There’s a large number of places that would need to be patched to achieve that. Upstream’s position is that any deprecated function must not be used in FIPS mode, and all ENGINE functions are deprecated. > Given that the symbols are intended to remain present in the ABI > it doesn't seem like this change would have any impact on FIPS > compatibility of openssl itself either way. That’s correct, but it pushes towards eventual compliance. > Is this proposed dummy engine.h a Fedora downstream invention or > something upstream does when engines are disabled ? Upstream’s engine.h defines nothing if OpenSSL was compiled without engine support, which is the setup we want to replicate. > Providing a dummy engine.h that does not actually contain any of > the definitions that engine.h is supposed to provide feels like > the kind of thing we should not do downstream only. It is liable > to break any configure time checks that look for engine.h as a > witness for being able to build engine support. Any such configure checks are already broken, because they do not take into account OpenSSL’s upstream configure option that makes this header a no-op. > Below it is said that the symbols remain present in the library, so > the attack surface remains unchanged AFAICS. Assuming it is intended > to keep the symbols functional, the maint burden doesn't seem > appreciably different either. Not at the moment, but it does force Fedora to move off engines, and thus makes it a lot easier to drop them in the future. If we don’t do this now, and OpenSSL 4 removes them eventually, the moment we show up with a change proposal to update OpenSSL to 4, the same people will shout that engines are no longer available. Anybody who is still relying on engines needs to start looking at a transition, the earlier the better. At best, you’re buying yourself a year by rejecting this change. -- Clemens Lang RHEL Crypto Team Red Hat -- _______________________________________________ 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
