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

Re: Linking coreutils against OpenSSL



Hi!

On Thu, 2023-11-09 at 17:38:05 -0500, Benjamin Barenblat wrote:
> coreutils can link against OpenSSL, yielding a substantial speed boost
> in sha256sum etc. For many years, this was inadvisable due to license
> conflicts. However, as of bookworm, coreutils requires GPL-3+ and
> OpenSSL is Apache-2.0, so I believe all license compatibility questions
> have been resolved.
> 
> What would you think about having coreutils Depend on libssl3? This
> would make the libssl3 package essential, which is potentially
> undesirable, but it also has the potential for serious user time savings
> (on recent Intel CPUs, OpenSSL’s SHA-256 is over five times faster than
> coreutils’ internal implementation).

This increases the pseudo-essential-set by around 6 MiB, to increase
performance for the digest tools, which do not seem like something
that gets run too often? So the trade-off here does not seem worth it
to me TBH.

The other thing is that the OpenSSL support seems to be coming from
gnulib, which is using the deprecated low-level digest functions from
OpenSSL (supposedly to be removed in the future), and where the
supported high-level ones have the problem (AFAIUI) of being affected
by the OpenSSL policies (such as FIPS or other config or similar) which
could then render those commands unusable once and if they switch API.
This is one of the reasons for why I switched dpkg from its embedded
digest functions to use libmd (currently pseudo-essential) instead one
of the other crypto libs. Of course libmd does not currently contain
optimized functions, but I'd be happy to take patches for that, or might
eventually look into adding support to it to use the Linux Kernel Crypto
API or similar.

Thanks,
Guillem


Reply to: