Details
-
Type:
Bug
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: mariadb
-
Labels:
-
Team:Data Access and Database
Description
I have a build failure in daf_persistence due to mariadbclient not linking to libssl/libcrypto on a linux machine. Can we make the ssloptions fix for OSX apply generically, or would that break something else?
Here's the daf_persistence error that I received:
daf_persistence: 2016_01.0-1-gf47bb69 ERROR (33 sec).
|
*** error building product daf_persistence.
|
*** exit code = 2
|
*** log is in /astro/apps6/opt/lsstStacks/lsstsw/build/daf_persistence/_build.log
|
*** last few lines:
|
::::: [2016-02-17T23:03:47.312613Z] /astro/apps6/opt/lsstStacks/lsstsw/stack/Linux64/mariadbclient/10.1.11/lib/libmysqlclient_r.so: undefined reference to `SSL_CTX_ctrl'
|
::::: [2016-02-17T23:03:47.312663Z] /astro/apps6/opt/lsstStacks/lsstsw/stack/Linux64/mariadbclient/10.1.11/lib/libmysqlclient_r.so: undefined reference to `ERR_get_error'
|
::::: [2016-02-17T23:03:47.312765Z] /astro/apps6/opt/lsstStacks/lsstsw/stack/Linux64/mariadbclient/10.1.11/lib/libmysqlclient_r.so: undefined reference to `SSL_new'
|
::::: [2016-02-17T23:03:47.312815Z] collect2: error: ld returned 1 exit status
|
::::: [2016-02-17T23:03:47.312834Z] scons: *** [tests/DbStorage_1] Error 1
|
::::: [2016-02-17T23:03:47.735155Z] /astro/apps6/opt/lsstStacks/lsstsw/miniconda/lib/python2.7/config/libpython2.7.a(posixmodule.o): In function `posix_tmpnam':
|
::::: [2016-02-17T23:03:47.735289Z] -------src-dir-------/Python-2.7.11/./Modules/posixmodule.c:7631: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
|
::::: [2016-02-17T23:03:47.735345Z] /astro/apps6/opt/lsstStacks/lsstsw/miniconda/lib/python2.7/config/libpython2.7.a(posixmodule.o): In function `posix_tempnam':
|
::::: [2016-02-17T23:03:47.735400Z] -------src-dir-------/Python-2.7.11/./Modules/posixmodule.c:7578: warning: the use of `tempnam' is dangerous, better use `mkstemp'
|
::::: [2016-02-17T23:03:47.764830Z] scons: building terminated because of errors.
|
Here's what my mariadb lib linkage looks like, with the missing libs:
[16:32:53 parejkoj@magneto: /astro/apps6/opt/lsstStacks/lsstsw/stack/Linux64/mariadbclient/10.1.11/lib]
$ ldd libmysqlclient.so.18.0.0
linux-vdso.so.1 => (0x00007ffdb63b4000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f088ab10000)
libz.so.1 => /lib64/libz.so.1 (0x00007f088a8f9000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007f088a6f4000)
librt.so.1 => /lib64/librt.so.1 (0x00007f088a4ec000)
libstdc+.so.6 => /usr/lib64/libstdc+.so.6 (0x00007f088a1e6000)
libm.so.6 => /lib64/libm.so.6 (0x00007f0889f61000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0889d4b000)
libc.so.6 => /lib64/libc.so.6 (0x00007f08899b7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f088b2af000)
Well, the only issue I see is that the system SSL libraries are updated frequently and in a timely fashion in response to CVE alerts, etc. What is the vulnerability of MariaDB's internal SSL implementation? I'd be interested in the point of view of somebody more security-conscious here (maybe Joshua Hoblitt?)
I haven't really cared too much to date about the OSX builds of qserv, since they aren't currently intended to be supported for production use. So, whatever works for the convenience of devs on OSX is okay for me, in order to get the bonus of having clang run regularly over our code.