MySQL Bugs: #103227: Building on Mac OS with SSL incorrectly copies SSL libraries

Bug #103227	Building on Mac OS with SSL incorrectly copies SSL libraries
Submitted:	6 Apr 2021 16:33	Modified:	17 Dec 2021 21:03
Reporter:	David Cantrell	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S3 (Non-critical)
Version:	8.0.23	OS:	MacOS (Catalina)
Assigned to:		CPU Architecture:	x86 (64 bit)
Tags:	build, SSL

Description:
Building WITH_SSL and specifying which ssl libs to use, the Mysql build system links code against the libs at the path you told it but copies those libraries alongside its own libs into the CMAKE_INSTALL_PREFIX directory, potentially overwriting what was there already or installing a copy of the specified libraries earlier in the path than is expected. This can cause other software to fail as the libs they are linked against unexpectedly change.

While I have found this on Catalina 64 bit, I doubt it is restricted to just that particular version.

How to repeat:
Build mysql, using `-DWITH_SSL=/path/to/ssl/libs`.

Suggested fix:
Don't copy the SSL libraries into CMAKE_INSTALL_PREFIX. Do put their location into mysql_config so that software which wants to talk to MySQL securely can do so using the correct SSL libs.

correct severity

Hi,

Thank you for the report, it happens on bensur too, I don't think it's related to OSX version but on how cmake works. I'm not 100% sure if it has to do with cmake tool itself or with our cmage script, build team will handle this.

All best
Bogdan

Posted by developer:
 
There are two different issues here:

- Whether to copy SSL libraries or not.
- Output of mysql_config

We should consider changing our cmake code to allow treating homebrew
equivalent to system libraries on Linux. The current set of system
libs used when building MySQL are:
SET(SYSTEM_LIBRARIES
  CURL
  EDITLINE
  ICU
  LIBEVENT
  LZ4
  PROTOBUF
  SSL
  ZLIB
  ZSTD
  )
I don't know whether all of these are provided by homebrew.

I know some developers use -DWITH_PROTOBUF=system (rather than bundled),
and this has caused build breaks because homebrew sometimes has a protobuf
version we have never built/tested with.

When we (MySQL/Oracle) make tarballs to be uploaded here:
https://dev.mysql.com/downloads/mysql/
we do not want to have any dependencies on homebrew, hence we copy SSL
libraries into the package.

The output from mysql_config on Mac is:

./bin/mysql_config --libs
-L<install path>/mysql/lib -lmysqlclient -lssl -lcrypto -lresolv

And this, IMHO, is correct if we have copied the SSL libraries.
Any client linking with the MySQL client library, should use the same
SSL libraries as the client lib itself. 

When running cmake without any WITH_SSL argument, I end up with:
otool -L lib/libmysqlclient.21.dylib
lib/libmysqlclient.21.dylib:
        @rpath/libmysqlclient.21.dylib (compatibility version 21.0.0, current version 21.0.0)
        /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

If I do cmake -DWITH_SSL=/path/to/some/ssl-installation, I get:
otool -L lib/libmysqlclient.dylib 
lib/libmysqlclient.dylib:
        @rpath/libmysqlclient.21.dylib (compatibility version 21.0.0, current version 21.0.0)
        @loader_path/../lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        @loader_path/../lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

So if you do -DWITH_SSL=/path/to/ssl/libs those libs must be
copied. That's how we bundle libraries to avoid any homebrew
dependencies. 

If you do -DWITH_SSL=system (which is the default anyways)
we should avoid copying them.

Thanks for your reply, Tor. Homebrew maintainer here. (For reference, we do provide all the system libraries you've listed.) 

I tried to build this on ARM64 (Big Sur).

Even passing -DWITH_SSL=system (or even omitting this flag entirely) libssl and libcrypto (plus symlinks) are still copied into mysql's lib directory.

If I understand your comment correctly, this is not what is supposed to be happening in this case.

To be clear, the issue isn't about getting the correct linkage for MySQL libraries such as libmysqlclient. The output of otool when we pass -DWITH_SSL=path/to/ssl shows correct linkage to the libraries we want (i.e. the libraries located in the path we provided).

Sorry for the confusion. There is a bug in our cmake code, we should not be copying system libs around, but we still do. I just haven't gotten around to fixing it yet.

That's fine; I just wanted to make sure we were on the same page about whether there is a bug here and what the bug is.

I hope mysql_config can be fixed with this as well.

Posted by developer:
 
Fixed in 8.0.29.
Build configuration changed, no changelog entry required.