Bugzilla – Bug 1210313
Conflict resolution between openssl and libressl
Last modified: 2024-07-03 13:08:57 UTC
I'm opening this bug to discuss Jan Engelhardt's initiative to unify/simplify ssl-devel provides in ssl packages. It seems to be more complex than I originally thought and it has high potential to break something. Currently there are following requests: libressl: https://build.opensuse.org/request/show/1078122 (in staging) openssl: https://build.opensuse.org/request/show/1077018 openssl-1_1: https://build.opensuse.org/request/show/1076424 openssl-3: https://build.opensuse.org/request/show/1076425 Let's discuss it here to avoid 1:1 discussions and/or multiple discussions in each request/package. I see problem with adding 'Conflicts: openssl(cli)'. Then we won't be able to install both versions (openssl-3 and openssl-1_1) at the same time. It's desired to be able to install both versions (cli, not devel) Regarding 'Provides/Conflicts: ssl-devel' Pedro told me that it was discussed with Marcus, can you please summarize your conclusion?
>It's desired to be able to install both versions (cli, not devel) How could you possibly co-install the openssl-1_1 and openssl-3 CLIs, when both of them supply a /usr/bin/openssl file? …And now that I look at it, someone renamed /usr/bin/openssl to /usr/bin/openssl-1_1. Which openssl-1_1 probably should not provide "openssl(cli)" at all, because openssl-1_1.rpm no longer factually conflicts on /usr/bin/openssl. I shall update the SRs in short order.
(In reply to Otto Hollmann from comment #0) > I'm opening this bug to discuss Jan Engelhardt's initiative to > unify/simplify ssl-devel provides in ssl packages. It seems to be more > complex than I originally thought and it has high potential to break > something. > > Currently there are following requests: > libressl: https://build.opensuse.org/request/show/1078122 (in staging) > openssl: https://build.opensuse.org/request/show/1077018 > openssl-1_1: https://build.opensuse.org/request/show/1076424 > openssl-3: https://build.opensuse.org/request/show/1076425 > Let's discuss it here to avoid 1:1 discussions and/or multiple discussions > in each request/package. > > I see problem with adding 'Conflicts: openssl(cli)'. Then we won't be able > to install both versions (openssl-3 and openssl-1_1) at the same time. It's > desired to be able to install both versions (cli, not devel) > > Regarding 'Provides/Conflicts: ssl-devel' Pedro told me that it was > discussed with Marcus, can you please summarize your conclusion? Hi, Otto. I discussed with Marcus that the conflict between libopenssl-3-devel and libopenssl-1_1-devel must stay as we want to only ship libopenssl-3-devel. Note that, the latter has all the functions available from version 1.1.1x, only some are marked as deprecated and some low level functions cannot be accessed directly. Marcus also mentioned if "Conflicts: otherproviders(ssl-devel)" could be used in this case. When I submitted the openssl-3 as the default openssl some months ago, I removed the conflicts/provides for ssl and openssl(cli) as there was no conflict anymore but I completely forgot about libressl, see my submission: * https://build.opensuse.org/request/show/1062217 My bad ;) Sorry about that! The problem surfaced in libressl when Jan submitted the latest update and added conflicts for openssl(cli) and ssl-devel see: * https://build.opensuse.org/request/show/1078122 HTH
>the conflict between libopenssl-3-devel and libopenssl-1_1-devel must stay it stays by way of Provides+Conflicts: ssl-devel >Marcus also mentioned if "Conflicts: otherproviders(ssl-devel)" could be used in this case the syntax is obsoleted by `Provides: ssl-devel`+`Conflicts: ssl-devel`
Jan, thanks for the new submissions! Our idea was to only provide the libopenssl-3-devel package since all the public functions from libopenssl-1_1-devel are included in there, only some functions are marked as deprecated and some low level functions cannot be accessed directly anymore. Using libopenssl-1_1-devel instead of libopenssl-3-devel can lead to problems now that openssl-3 is the default and it doesn't add much to include it. Note that, I won't oppose to ship also libopenssl-1_1-devel in conflict to libopenssl-3-devel and leave the decision to the user. Please, consider also including this bug number to the changelog entry for tracking purposes.
1082947 1082948 1082949 let's just get this done soon!
There are 3 things you would like to change in your requests: * devel packages conflicts: Adding "Provides/Conflicts: ssl-devel" seems to be fine from my point of view. In past it was there and make sense to add it. Also it's present in openssl-1_0_0. Removing explicit conflicts with other libraries like "Conflicts: libopenssl-3-devel" should be also fine, conflicts should be resolved by "ssl-devel". * library conflicts - libressl openssl3 Now, conflicts are handled "only" by "Conflicts: ssl" in openssl3. We should add the same also into libressl. Or resolve this conflicts using "Provides/Conflicts: openssl(cli)". Maybe we should add both: > Conflicts: ssl > Provides: ssl > Conflicts: openssl(cli) > Provides: openssl(cli) Because there are two "types" of conflicts, one in binary /usr/bin/openssl (man pages, etc) and second in directory /etc/ssl. What's your opinion? * meta package Removing "Provides" from meta package should be also fine. It requires (default) openssl-3 package and openssl-3 requires openssl. So both must be installed at same the time and "Provides: openssl(cli)" will be provided by openssl-3 package.
libressl.spec already has had Provides/Conflicts: ssl that spans to protect {/etc/openssl and /usr/bin/openssl} against competing implementations.
(In reply to Jan Engelhardt from comment #7) > libressl.spec already has had Provides/Conflicts: ssl that spans to protect > {/etc/openssl and /usr/bin/openssl} against competing implementations. It's only in devel project, I was comparing it with Factory version. I discussed this issue with Pedro and we came up with the following proposal: * Add Provides/Conflicts: ssl-devel into all openssl and libressl packages (except openssl meta package) * Remove explicit devel conflicts * Add/keep Provides/Conflicts openssl(cli) in folowing packages: openssl-1_0_0, openssl (meta) and libressl. We would like to keep it in meta package because once next major version will be released, we will rename openssl-3 binary and it won't conflict with libressl anymore. * Remove Conflicts: ssl and add/keep Provides: ssl in all *ssl packages. We are not sure if this is necessary, because no other package require it, so theoretically it can be removed completely. * Remove Obsoletes: ssl You can see above changes in my project: https://build.opensuse.org/project/show/home:ohollmann:branches:security:tls:unstable Once we agree on this changes, I will add changelog entry and create SR. @Dominique, @Jan, @Marcus, what do you think about it?
It is really difficult to determine diffs of diffs, so just pick/merge one proposal, and then we'll iterate if anything is left.
Hi Jan, I submitted changes for OpenSSL into security:tls project and created request (cleanup only) for libressl: > https://build.opensuse.org/request/show/1095564 Please review it and then we can forward it into Factory. I'm apologize for delay.
This is an autogenerated message for OBS integration: This bug (1210313) was mentioned in https://build.opensuse.org/request/show/1095600 Factory / libressl
This is an autogenerated message for OBS integration: This bug (1210313) was mentioned in https://build.opensuse.org/request/show/1095606 Factory / openssl https://build.opensuse.org/request/show/1095607 Factory / openssl-3 https://build.opensuse.org/request/show/1095609 Factory / openssl-1_1 https://build.opensuse.org/request/show/1095610 Factory / openssl-1_0_0
https://openqa.opensuse.org/tests/3388753#step/zdup/12 There is now a problem with trying to update from 15.4 to TW; upgrade path is completely broken with the latest openssl submissions (granted, only 1.1 and 1.0 are in - I see openssl 3 and openssl meta package are not accepted in the same snapshot)
This issue seems to be caused by added > Conflicts: openssl(cli) into openssl meta package in Tumbleweed. Then it conflicts with openssl-1_1 (from 15.4) because it has > Provides: openssl(cli) The meta package from 15.4 doesn't have any Provides/Conflicts. That's maybe another reason why conflicts should be handled by meta package but I don't know how to fix if and I don't think we will be allowed to change it in 15.4/SLE* It seems that the only is to keep devel conflicts and revert other changes. Or at least revert change that caused this issue.
There is another issue related to this I stumbled over today: I did a clean reinstall of Tumbleweed, when pulling the build dependencies for libzypp I ended up with libressl-devel and libopenssl3 installed. The build still runs against the libressl headers and even links, but the end result is broken: Ldd of the resulting binary shows that its linking against this ssl: > libssl.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libssl.so.3.1.4 (0x00007f626f824000) And against 2 variants of libcrypto: > libcrypto.so.50 => /lib64/libcrypto.so.50 (0x00007f455a400000) > libcrypto.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libcrypto.so.3.1.4 (0x00007f4559e00000) At buildtime I get the warning: > /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: warning: libcrypto.so.3, needed by /usr/lib64/libzck.so, may conflict with libcrypto.so.50 Executing the binary it fails and exits with the error: > 39620905237184:error:0EFFF065:configuration file routines:CRYPTO_internal:missing equal sign:conf/conf_def.c:346:line 57 This probably happens because libressl-devel provides pkgconfig(openssl), which is what we require in the rpm build, but the packages are not protected against a mixed install.
A mixed install is not supposed to be a problem (other than the fact that one has a mixed install to begin with): https://build.opensuse.org/package/view_file/security:tls/libressl/extra-symver.diff?expand=1 There are also pending requests that get no attention. 1126565 1126566
> 39620905237184:error:0EFFF065:configuration file routines:CRYPTO_internal:missing equal sign:conf/conf_def.c:346:line 57 This error is not because of library mixing, but because SUSE's openssl-3 has been patched with openssl-crypto-policies-support.patch to support *and distribute* a non-standard config file format that neither an unmodified openssl nor an unmodified libressl are able to understand. +[ crypto_policy ] + +.include = /etc/crypto-policies/back-ends/opensslcnf.config
(oh well, .include was added to openssl upstream at b524b808a1d1ba204dbdcbb42de4e3bddb3472ac) Another issue is that /etc/ssl/openssl.cnf is provided only if you have openssl-3 installed, but it is exercised by libcrypto itself.
(In reply to Jan Engelhardt from comment #25) > A mixed install is not supposed to be a problem (other than the fact that > one has a mixed install to begin with): One thing I noticed is that libressl has a lower openSSL API level than OpenSSL. So if we allow mixed install of e.g. libressl-devel + libopenssl3 we have to be sure that compiling against libressl headers and linking to openssl3 is not an issue.. Also in the end my binary had 2 libcrypto linked, yes I got a build time warning but if tests hadn't failed I'd probably not have noticed it. Judging from the warning it seems that zchunk pulled in the other one: > /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: warning: libcrypto.so.3, needed by /usr/lib64/libzck.so, may conflict with libcrypto.so.50 (In reply to Jan Engelhardt from comment #26) > > 39620905237184:error:0EFFF065:configuration file routines:CRYPTO_internal:missing equal sign:conf/conf_def.c:346:line 57 > > This error is not because of library mixing, but because SUSE's openssl-3 > has been patched with openssl-crypto-policies-support.patch to support *and > distribute* a non-standard config file format that neither an unmodified > openssl nor an unmodified libressl are able to understand. I see, thats why google also did not bring anything helpful up...