Rationalize openssl and libressl package relationship
(Apologies if I’m treading old ground. I did a search through the bug database and nothing seemed to directly address this.)
I’m building a Docker image with Alpine that contains mariadb, curl, and other projects that depend on [open|libre]ssl. It also contains R, including several R packages that must be installed from CRAN. The foundation SSL package in CRAN, openssl, does not, at this writing, load against libressl. Thus, it is necessary for me to use real-deal openssl at some point.
Alpine 3.5 currently contains both the openssl and libressl packages, as well as openssl-dev and libressl-dev. These packages provide the same interface and conflict with each other. Packages such as mariadb seem to be looking for libssl and friends, so uninstalling libressl and installing openssl succeeds. (I haven’t tested that it works at runtime; since I presume the binary packages are linked against libressl, that’s a significant open question in my mind.)
The mariadb-dev and curl-dev packages (and presumably every other -dev package with a dependency on [open|libre]ssl) have an explicit dependency on libressl-dev that openssl-dev does not satisfy. So even if libssl et al. from openssl are ABI-compatible with their counterparts in libressl, installing openssl as a replacement for libressl makes it impossible to install mariadb-dev, curl-dev, and (presumably) other dev packages for projects using the openssl ABI if openssl and openssl-dev are installed.
I don’t think it’s reasonable to ask Alpine Linux to be responsible for third parties who haven’t made their tools compatible with libressl. (I have a bug out with the R openssl project that I hope will encourage them to do this work.) It would be nice, however, if Alpine made it easier to cope with this unfortunate reality as people transition, especially since R is a major addition to 3.5. At a minimum, I think the Alpine linux openssl and libressl packages should be organized such that users can request to install any combination of packages (such as openssl-dev and mariadb-dev) and either get a working system or a straightforward explanation of what’s wrong with what they’re asking for.
Removing openssl and openssl-dev entirely is one option. For my use case, this seems to require building openssl on the side. This might present some usability problems with R users who depend on the R openssl package. (Analogous problems may exist in other languages’ packaging systems, but R is the one I’ve noticed and is a major new addition to Alpine, so it’s likely to be the biggest pain point.) One mitigation would be to package the R openssl package as an Alpine package and patch it to use libressl.
Doing nothing is also an option, basically just like removing openssl but more confusing. I see no way in which removing the openssl packages isn’t better than doing nothing.
Alpine could also provide openssl(-dev) and libressl(-dev) as first class replacements for one another, both providing the OpenSSL ABI. This seems to represent a lot of work for very little gain, and with significant drawbacks. A more secure SSL library is a feature; Alpine should use it wherever it can.
My favorite solution of the ones I’ve considered so far is to make the openssl packages install openssl off to the side somewhere, so they will not normally be used, but a user can explicitly link and load against them if necessary. This would require some work retooling the openssl packages and documenting the procedure for including the openssl headers and libraries where necessary. On the bright side, both sets of packages can coexist, Alpine packages can always use the more secure libressl, and users have a documented recourse for building modules from third parties who aren’t with the program.
Whatever you choose, I’d argue the status quo is a bug. Openssl and openssl-dev, as they currently exist, are strictly inferior to libressl and libressl-dev. If they’re installed, they cause apk to throw unexpected errors when users try to install packages like mariadb-dev, and at best they provide versions of libssl and libcrypto that work, but not as securely as libressl’s. Removing them is better than doing nothing, IMO.
(from redmine: issue id 6604, created on 2016-12-29)