Linux build links openssl dynamically

[pmconrad]

See bitshares/bitshares-core#1979

Bug Description
Downloaded from https://github.com/bitshares/bitshares-core/releases/download/3.3.1/bitshares-core-3.3.1-linux-amd64-bin.tar.bz2

./witness_node: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
./cli_wallet: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

[pmconrad]

It would be possible to create the builds with statically linked openssl (see bitshares/bitshares-core#1980). There are pros and cons though.

Pro:

• statically linked binaries are more likely to run in different environments, due to fewer external dependencies

Con:

• Security updates for libraries provided by the OS to not apply automatically to static binaries, whereas they do for dynamic libs.
• Security updates for openssl would require a rebuild, and rebuilds would make the existing signatures obsolete.
• Even worse, the build result changes after a security update, i. e. the original build result can no longer be reproduced.

We have to find a tradeoff here. Opinions @abitmore @ryanRfox ?

[abitmore]

Right now I still prefer statically linking openssl.

the original build result can no longer be reproduced.

I think the original build result can still be reproduced with the original gitan setup. When rebuilding, we need to update gitan setup, since the setup is managed with git, the old configurations won't get lost.

With this in consideration, in order to reproduce the build results, we need to clearly describe what revision of bitshares-gitan is used for building the binaries in the release notes page, even mention versions of dependencies used to build the binaries.

In case when a security update is available, we need to

• update gitan setup and rebuild,
• upload new binaries,
• remove old binaries,
• update release notes,
• add new signatures,
• notice users of the binaries to update.

Actually this is important, but was ignored in the past. I hope we don't need to do it frequently.

@ryanRfox please invite other team members and even community members to discuss this.

[pmconrad]

I think the original build result can still be reproduced with the original gitan setup.

Gitian automatically installs latest package versions on each run. I also believe that outdated package versions are no longer available in Ubuntu repos, so I think it would not work if we explicitly specified certain package versions for the build.

An alternative would be to do it for linux as is done for windows + mac builds - download openssl source package and use that.

I hope we don't need to do it frequently.

Static linking also puts the burden of monitoring this on us. OTOH we should keep an eye on it for win + mac anyway, as well as for the other statically linked libs (curl, boost). Sigh.

[abitmore]

An alternative would be to do it for linux as is done for windows + mac builds - download openssl source package and use that.

I thought we did the same for all OS's.

[pmconrad]

I thought we did the same for all OS's.

My approach was to use what's there and build only what's needed.

Since we have to monitor and update libraries for mac and windows binaries anyway, I think it makes sense to use the same process for linux as well.

I'm about to configure an external change notification service so notify me on changes to the following websites:

• https://www.openssl.org/news/vulnerabilities.html
• https://curl.haxx.se/docs/security.html
• https://www.zlib.net/
• https://www.cvedetails.com/vulnerability-list/vendor_id-7685/Boost.html

...and modify the linux build to use self-compiled openssl as well (it already builds a static libcurl). If necessary also boost.

[pmconrad]

Found another con:

• The location of the default CA certificates is distribution-dependent. With a static openssl we have to compile a default path into cli_wallet. Dynamic libs would use the system default.