Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

> On 20. Mar 2024, at 18:11, Joe Orton <jorton@xxxxxxxxxx> wrote:
> 
> On Wed, Mar 20, 2024 at 02:05:52PM +0000, Daniel Berrange wrote:
>> Another alternative is to continue providing fully functional engine
>> symbols, but remove the header files so in practice you can't compile
>> something new that uses it. This is still forking the API, but at least
>> has not forked the ELF ABI, so the upgrade doesn't explode.
> 
> This is a really good idea, I hope Daniel's comment is not lost here.

It isn’t, we are very much aware of this possibility and have already discussed it before.

The ENGINE API is a source of subtle bugs especially when used together with providers, though, so we would really prefer to disable it completely rather than keeping it around. PKEY objects backed by an ENGINE use a number of different lesser tested code paths in the OpenSSL source code, which lead to all sorts of weird an inconsistent behavior.


> On 20. Mar 2024, at 16:07, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
> 
> Sorry, but the idea to drop symbols without changing the SONAME
> must be rejected. If upstream plans to drop the symbols for 4.0, then
> that is OK, assuming that the SONAME is bumped then.


This does already not match reality. OpenSSL provides a number of symbols that are dependent on compile-time options. Take a look at [1, 2]. Every symbol in there that is tagged with EXIST::FUNCTION followed by a string that is not DEPRECATEDIN_3_0 is only present when the associated configure-time option is enabled.

For example, an OpenSSL configured with no-des will not provide the DES_xcbc_encrypt symbol. The assumption that one specific SOVERSION of OpenSSL will always contain the same symbols on all operating systems is thus incorrect. Obviously this is not a change that can be made during the lifetime of a specific Fedora release, but ahead of a mass rebuild, it should be doable to land a change such as this without changing the SONAME, considering the problem you want to avoid with the SONAME bump *already* exists between different builds of OpenSSL with different configuration.


[1]: https://github.com/openssl/openssl/blob/master/util/libssl.num
[2]: https://github.com/openssl/openssl/blob/master/util/libcrypto.num


-- 
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux