cossacklabs / themis / #7783 / 1
88%
master: 83%

LAST BUILD BRANCH: release/0.15.0
DEFAULT BRANCH: master
Ran
Files 73
Run time 17s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 87.712%. Remained the same
#7783.1

push

travis-ci

web-flow 
Include embedded BoringSSL into libsoter.a (#681)

* Include embedded BoringSSL into libsoter.a

Currently, when building Themis with embedded BoringSSL (the one from
git submodule), the shared library is linked against the BoringSSL
static library and it is embedded into the dylib. That way resulting
Themis dylib does not depend on the system OpenSSL. Instead it uses
the BoringSSL which we build and embed into it.

However, right now Themis static library does not include embedded
BoringSSL in it. The user is expected to find "libcrypto.a" and
"libdecrepit.a" in BoringSSL build directory, distribute them along with
"libthemis.a" and "libsoter.a", and include all four libraries when
building the application.

Why is this an issue?
---------------------

This is not particularly convenient since BoringSSL libraries are buried
in the BoringSSL build directory, not available in the usual Themis
build directory. It is quite possible that developers will forget about
them entirely. They are also not included into the packages we build.

Furthermore, Soter is built with and expects that particular version of
BoringSSL to be linked into the application. While BoringSSL generally
does a good job at maintaining ABI compatibility, the user may
accidentally link some OpenSSL from their system instead of BoringSSL
that was built with Themis. This may break in a subtle way.

How we resolve it
-----------------

In order to avoid all those issues, let's embed BoringSSL into Soter
static library, like we do with the shared library. That way the users
will have to link only against "libthemis.a" and "libsoter.a".

Note that this is actual only for the case when we are building Themis
with embedded BoringSSL. That is, the BoringSSL we provide in submodule.
We should not embed system OpenSSL, or any BoringSSL built and provided
by the user. In that case the users are expected to take care of the
cryptography provider library thems... (continued)

3776 of 4305 relevant lines covered (87.71%)

19286.97 hits per line

Source Files on job #7783.1