CentOS, RHEL 6+ and SuSe Linux defect for libcrypto.so.1.0.0

[piotr-iohk]

Release	Operating System	Cause
next	Linux	Code v Configuration v Environment v Human v Unknown

Context

It seems that libcrypto 1.0.0 is no longer shipped with RHEL for a while (since ver. 6) and it is impossible to install it using native package manager yum.

Seem to be the same for SuSe Linux and CentOS (which is derived from RHEL).

libcrypto 1.0.0 is a dependency of cardano-wallet (through cardano-crypto probably).

Steps to Reproduce

On RHEL 8 run cardano-wallet.

Expected behavior

It works.

Actual behavior

$ cardano-wallet 
cardano-wallet: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

Workaround is possible if there is a newer libcrypto present on the system e.g.:

sudo ln -s /usr/lib64/libcrypto.so.1.1.1 /usr/lib64/libcrypto.so.1.0.0

---

Resolution Plan

PR

Number	Base
#1052	master

QA

• Added a note in the Linux installation instructions of the release template.

[rvl]

There are other issues too -- for example, it won't work if the user's glibc version is too old (usually happens with RHEL/Centos or Debian stable). Also there are support difficulties around asking users to find and install the right libraries.

The two best ways to produce Linux builds which run in many environments are:

1. fully static binary (not dynamically linked at all)
2. docker image

The fully static binary will require some help from tools team.

The docker image is simple to do, and requires about 20 LOC of nix code, plus a buildkite script to push to dockerhub.

[KtorZ]

By the by @rvl, I've asked our legal representatives about the licensing issues that could cause a static linking with some libraries. Their answer is:

Thanks - even easier. In a nutshell, other more restrictive licenses are not a problem. We / IOHK can stick to our Apache 2.0 license.
The only thing we need to do is to point out other (less or more restrictive) licenses applicable to elements/code/ modules that we have used within our code.

I believe we should aim for both 1. and 2. in the upcoming releases.

[plessmann]

For debian 10 (buster) you'll need a symlink like this as workaround:

ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /usr/lib/libcrypto.so.1.0.0

[thevictor13]

For debian 10 (buster) you'll need a symlink like this as workaround:

ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /usr/lib/libcrypto.so.1.0.0

The above also applies for Ubuntu Server 19.10