Hi,

> On 25. Feb 2025, at 10:29, Daniel P. Berrangé <berra...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to