On Tue, Feb 25, 2025 at 01:57:35PM +0100, Clemens Lang wrote: > > > 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. Sure, that's true, but in practice with distros shipping engine APIs enabled by default historically this will potentially be a new situation for apps in general. > > 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. At a major version change apps would be expecting this kind of breakage anyway, so that's more reasonable and presumably why openssl didn't just rip engines out of v3 and instead deprecated until v4. At that point the decision is forced by upstream so the pros/cons will have shifted. ie the debate is between fedora getting stuck on openssl 3 forever (not viable), vs breaking any use of engine APIs. > 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. The deprecation is a clear indicator for the transition, and these repeated change proposals have given notice to maintainers. I'm still not finding it compelling to prematurely force the breakage on people while upstream is still shipping this functionality. Right now the benefits to Fedora seem to be minimal, with clear breakage & disruption potential. Once OpenSSSL 4 ships, then the benefits to Fedora to update to that are compelling, despite any potential breakage, so the balance changes and I would support that. 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
