Package Themis Core with BoringSSL #683
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Strictly speaking, libthemis depends on the OpenSSL library, not the "openssl" binary. The "openssl" package installs the entire binary along with its man pages, etc. Instead, it is sufficient to depend only on the library. The library package is typically called "libssl1.1", with an ABI suffix. The default OpenSSL library version differs between distros so we cannot write it in Makefile, but we should depend on the OpenSSL library from the particular distribution. If we were using debhelper, this would have been resolved for us automagically, but we are using FPM. Therefore we will use the dependencies of "libssl-dev" package as a proxy for the current default OpenSSL library name. This should be good enough.
Similar to Debian/Ubuntu situation, the "openssl" package on RHEL/CentOS installs the "openssl" binary. The package with libraries only is called "openssl-libs", we should depend on that instead. RPM packages typically do not include ABI infromation in the name, though the distros here typically do not ship multiple ABIs of a library either so it's fine.
If we are building Themis with embedded BoringSSL, produce packages with "-boringssl" suffix in their names: - libthemis-boringssl - libthemis-boringssl-dev - libthemis-boringssl-devel Note that this affects only Themis Core packages. Other packages do not depend on the choice of the cryptographic backend and keep their names: - libthemispp-dev - libthemispp-devel - libthemis-jni - libphpthemis
If Themis Core package is built with embedded BoringSSL, it does not depend on the system OpenSSL anymore. Do not include OpenSSL library and development packages in dependencies of "libthemis-boringssl" and "libthemis-boringssl-dev" packages.
Since both flavors of Themis Core install effectively the same files, make them conflicting: - libthemis conflicts with libthemis-boringssl - libthemis-dev conflicts with libthemis-boringssl-dev This prevents simultaneous installation. The implementation is not the most beatiful one, but we need to make it symmetric as either package conflicts with the other one.
Both OpenSSL and BoringSSL flavors of Themis Core provide the same ABI and can be used interchangeably. Make sure that both can satisfy dependencies of libthemispp, libthemis-jni, and libphpthemis packages. Note, however, that libthemis-boringssl cannot be used with libthemis-dev and vice versa. Also note that in this case we need to keep the version specs in parentheses because --depends value is directly substituted into DEB's "Depends:" field. FPM will not add parthenses for us this time.
Previously PHPThemis did not include in its dependencies at all. Make sure it depends on either OpenSSL or BoringSSL flavor of it, similar to the "libthemis-jni" package.
ilammy
added
core
vixentael
approved these changes
Jul 21, 2020
| endif | ||
| PHP_DEPENDENCIES += --depends "$(PACKAGE_NAME) (>= $(VERSION)+$(OS_CODENAME)) | $(OTHER_PACKAGE_NAME) (>= $(VERSION)+$(OS_CODENAME))" |
| @@ -604,23 +604,44 @@ endif | |||
| # Packaging Themis Core: Linux distributions | |||
| # | |||
|
|
|||
| ifeq ($(ENGINE),boringssl) | |||
| ifeq ($(CRYPTO_ENGINE_LIB_PATH),) | |||
| PACKAGE_EMBEDDED_BORINGSSL := yes | |||
There was a problem hiding this comment.
so, if engine is boringssl, we'll pack boringssl as embedded library by default, right?
There was a problem hiding this comment.
If ENGINE=boringssl and ENGINE_LIB_PATH is not set. That is, if the user has requested a build with BoringSSL from Themis submodule, not with some user-provided BoringSSL build from user-specified location.
shadinua
approved these changes
Jul 21, 2020
Makefile
Outdated
| # If we were using native Debian packaging, dpkg-shlibdeps could supply us with | ||
| # accurate dependency information. However, we build packages manually, so we | ||
| # use dependencies of "libssl-dev" as a proxy. Typically this is "libssl1.1". | ||
| DEB_DEPENDENCIES += --depends $(shell apt-cache depends libssl-dev | grep 'Depends:' | cut -d: -f 2-) |
There was a problem hiding this comment.
Suggested change
| DEB_DEPENDENCIES += --depends $(shell apt-cache depends libssl-dev | grep 'Depends:' | cut -d: -f 2-) | |
| DEB_DEPENDENCIES += --depends $(shell apt-cache depends libssl-dev | grep 'Depends:' | cut -d: -f 2- | tr -d ' ') |
:)
There was a problem hiding this comment.
It will be adjusted like this after #682 is merged 👌
|
Dependencies have been merged, I've synced up this branch and resolved merge conflicts. If you want to make another review pass over the clean diff, this is the time. I'll merge it today if CI passes. (Let's hope GHA will work this time.) |
|
Well, GHA is stuck ¯\_(ツ)_/¯ |
This was referenced Jul 23, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR teaches
make deb,make deb_php,make rpmto build packages of Themis Core using embedded BoringSSL instead of system OpenSSL. This is useful in cases like #619, #657.When
ENGINE=boringsslis set, produced Themis Core packages will get a suffix:libthemis-boringssllibthemis-boringssl-devorlibthemis-boringssl-develThis is an alternative flavor of Themis Core which includes embedded BoringSSL instead of depending on system OpenSSL.
The BoringSSL and OpenSSL flavors provide the same ABI and install the same files. As such, they are mutually exclusive and conflict with each other to prevent simultaneous installation.
Other packages (
libthemispp-dev,libthemis-jni,libphpthemis) now depend on either OpenSSL or BoringSSL flavor. That is, any flavor can be installed to satisfy the dependency.How to build new packages
In short, running
will build and package BoringSSL flavor of Themis. This will also compile and package other packages which are identical to the OpenSSL version.
It's better to build OpenSSL and BoringSSL flavors in separate build directories right now. The build system does not expect incremental rebuilds with different configuration.
Dependency summary
The dependencies are as follows:
libthemislibsslX.Y(of any version)libthemis-boringsslof any version (new!)libthemis-boringssl(new!)libthemisof any versionlibthemis-devlibssl-devlibthemisof exactly the same versionlibthemis-boringssl-devof any version (new!)libthemis-boringssl-dev(new!)libthemis-boringsslof exactly the same versionlibthemis-devof any versionlibthemispp-devlibthemis-devorlibthemis-boringssl-devof exactly the same version (changed)libthemis-jnilibthemisorlibthemis-boringsslof at least the same version (changed)libphpthemis-php*libthemisorlibthemis-boringsslof at least the same version (new!)Ditto for RPM, with
s/dev/devel/g, etc.Checklist
Change is covered by automated tests(not really, only Builtbot)This PR depends on the previous ones: