Build embedded BoringSSL with symbol prefix

[ilammy]

Since PR #681, when building with ENGINE=boringssl, Soter embeds BoringSSL into its libraries, including static ones. This enables the users to link only against libthemis.a and libsoter.a, without having to salvage the BoringSSL binaries from the build directory (which are not included into packages).

What is the issue here?

However, embedding BoringSSL has a side effect. Due to the way static linkage works, all BoringSSL symbols from libsoter.a are indistinguishable from Soter symbols for exporting purposes. That is, any binary linked against libsoter.a will by default include and export all BoringSSL symbols. This is problematic because it can cause symbol conflicts. Dynamic libraries are not affected by this because we control what symbols are exported. That way BoringSSL stays inside Soter library and does not cause conflicts.

In order to avoid conflicts, start using BoringSSL's symbol renaming facility. EVP_sha256() will be renamed into SOTER_0_14_0_EVP_sha256() and all call sites from Soter will refer to this new symbol instead. This makes Soter's BoringSSL copy independent of any WhateverSSL is there in the binary.

How renaming works

Bad news here is that renaming requires building BoringSSL twice. First we build it to enumerate the symbols to rename, then it is built again, now with renamed symbols. All symbols need to be renamed, not only those used by Soter, because the entire BoringSSL library is embedded into Soter. We cannot simply enumerate and hardcode what we use.

After building BoringSSL with renamed symbols, Soter needs to use them in renamed form. For that it needs to be built with BORINGSSL_PREFIX define and <boringssl_prefix_symbols.h> in its include path. That header will perform actual renaming using C preprocessor.

Other build details

Previously Soter did not care about build order, but now BoringSSL needs to be built (possibly renamed) before Soter can be built.

Note that extracting symbols with BoringSSL tool requires Go. BoringSSL build itself requires Go so this is not a new dependency.

Disable BoringSSL renaming for certain systems

Enable BoringSSL symbol renaming by default for Linux and macOS desktop builds and disable it for WebAssembly builds.

AndroidThemis also uses BoringSSL, but it does not use Themis Makefile for that. It does not use renaming either.

Renaming is important only for the case of static libraries, and only desktop systems provide them in packages. Mobile systems use dynamic linkage for the most part and avoid symbol conflicts.

The default can be overridden from the command line:

make ENGINE=boringssl RENAME_BORINGSSL_SYMBOLS=no

or "yes" to enable it.

Checklist

• Change is covered by automated tests
• The coding guidelines are followed
• Public API has proper documentation
• Changelog is updated

[Lagovas]

wow, cool. never thought about that and have not seen such approaches )

[ilammy]

The build currently fails in CircleCI when building BoringSSL because of outdated Go version. CircleCI uses Go 1.9 while BoringSSL recommends using the latest stable version (Go 1.15 as of now). I have checked that using the latest version fixes the issue.

Well, given #709, I guess I'll just sit here and wait while the corpse of my enemy floats past me and then refresh this PR.

@shadinua, take a note for Buildbot on this.

[vixentael]

Very good idea! Let's see what we'll get!

[vixentael]

my guts tell me that this code might have unexpected sideeffects, but i've read it multiple times and can't find a problem 🤔