On Wed, Mar 20, 2024 at 07:15:56PM +0100, Clemens Lang wrote: > 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. I expect the following behaviour from Fedora (or any distro that cares about stability for users): - For a given SONAME, symbols are only ever added, never removed. - Ideally, symbol versioning is used. - ABI stability is also maintained for a given SONAME. - If support for a given symbol needs to be removed, it can be replaced by a stub that is noop or returns an error, as appropriate. This approach was discussed earlier in the thread. (This can be useful e.g. for functions that implement some optional functionality and programs using those functions can still work even if those specific functions stop working. For example, a library that implements a bunch of compression methods, and one of them starts returning an error, and the programs will fall back to a different compression method, is a case where this could be useful.) - SONAME changes happen only if absolutely necessary. This means that if I compile a program against a library in Fedora, it'll continue to function indefinitely, in the sense of the dynamic linker loading the program without fuss. If the SONAME changes, I'll need to either recompile or install the older version of the library with the old SONAME. Dependent packages, both from the distro and external, can use rpm dependencies to prevent upgrades that'd break programs. Obviously, the items in the list above are much easier if the library upstream does the right things. So please, don't ever change compilation options in Fedora in a way that would cause symbols to disappear. Certainly not during one release. But even doing this at a release boundary is bad. Zbyszek -- _______________________________________________ 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
