#22 split libcrypto from openssl-libs
Opened a year ago by cyberpear. Modified 5 months ago

right now, you get coreutils -> openssl-libs -> ca-certificates -> p11-kit-trust -> alternatives, also pulling in grep, sed, libffi, libtasn1, pcre, p11-kit, etc

and also ca-certificates -> coreutils circular dep

This change drops the size difference between the coreutils and coreutils-single packages to just 9620K and 3 packages versus the current 16196K and 14 packages


What is the actual gain you are trying to achieve with this split? Do you have a specific scenario of system in mind? A system without openssl-libs and ca-certificates will be most likely unusable in today's internet.

This would break the circular dependency chain ca-certificates->coreutils->openssl-libs->ca-certificates. Most packages pulling in openssl-libs only need libcrypto, not also libssl. This would allow smaller containers where no need for external network communication is necessary, and crypto to access services provided by the container is taken care of by the platform, such as by Istio or other Service Mesh.

This would allow removing several %posttrans RPM scriptlets that are currently required due to the circular dependency chain. This would also make the installation order more deterministic, helping provide better Reproducible Builds of systems, not just packages.

No, it would not break any dependency loop. It is not true that only libssl requires the ca-certificates. Libcrypto requires it as well. Putting the ca-certificates dep only to the package containing libssl would be wrong.

Besides, Istio or other service mesh will pull in libssl, because what they need is TLS, not just some generic crypto function.

@tmraz why does libcrypto require ca-certificates?

@simo Istio packages aren't generally installed in the same container as the application container.

I did some repoquery against Fedora 33 (non-modular) repo.
409 packages require both libssl and libcrypto.
392 packages require only libcrypto but not libssl.

Because libcrypto has X509_verify_cert() function which can very well use the default ca-certificates. So there might be applications that do certificate chain verification which expect the default cert store to be present and working that do not use anything from libssl.

Wouldn't that situation be correctly reflected by adding a Recommends for ca-certificates on libcrypto instead of a hard Requires?

Having recommends would still not break the dep loop until at least this issue is fixed:

https://github.com/rpm-software-management/rpm/issues/1346

And yes, using recommends instead of requires for ca-certificates would be logical in openssl-libs but it risks its own set of fallout as there definitely are cases where something currently depends on the ca-certificates installed where the recommends are not installed.

@tmraz could we go ahead and move to recommends in Rawhide?
If you think it's necessary, I can write a Change proposal for this so people won't be caught off guard in F35

I am no longer the primary maintainer of openssl. @saprasad is. So she should confirm this is acceptable change. I was not opposed to changing this dependency to Recommends but yeah, having a Change page would be a good idea as I suppose there might be some follow up changes needed in comps, etc.

@lorbus fine by me. +1 for Change proposal.

Login to comment on this ticket.

Metadata