On 24 Jul 2018, at 14:25, Yann Ylavic <ylavic....@gmail.com> wrote:
>> I’m not seeing that this functionality being PRNG, or the apparent
>> simplicity of it being relevant in any way.
>>
>> We’ve created a hard link between APR and OpenSSL, in a system where
>> we already have a clean DSO based system to interface with crypto and
>> other libraries.
>
> How is DSO harder or softer than linking when --with-crypto (and
> --with-openssl or any other crypto lib) is configured?
> To me, --with-openssl means link with openssl, just like
> --with-libxml2 or --with-expat.
It doesn’t mean that no, I think this is the source of the confusion.
To explain this, look at how Redhat packages APR into discrete RPMs, each
limiting the scope of the transitive dependencies that get dragged in.
apr-util-ldap.x86_64 : APR utility library LDAP support
apr-util-mysql.x86_64 : APR utility library MySQL DBD driver
apr-util-nss.x86_64 : APR utility library NSS crytpo support
apr-util-odbc.x86_64 : APR utility library ODBC DBD driver
apr-util-openssl.x86_64 : APR utility library OpenSSL crytpo support
apr-util-pgsql.x86_64 : APR utility library PostgreSQL DBD driver
apr-util-sqlite.x86_64 : APR utility library SQLite DBD driver
apr-util.x86_64 : Apache Portable Runtime Utility library
apr.x86_64 : Apache Portable Runtime library
APR itself is tiny, and has very few library dependencies:
[root@tools ~]# ls -al /usr/lib64/libapr-1.so.0.6.3
-rwxr-xr-x. 1 root root 240504 Jun 9 13:03 /usr/lib64/libapr-1.so.0.6.3
[root@tools ~]# ldd /usr/lib64/libapr-1.so.0.6.3
linux-vdso.so.1 => (0x00007ffcd61ae000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f98f382a000)
librt.so.1 => /lib64/librt.so.1 (0x00007f98f3622000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f98f33eb000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f98f31cf000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f98f2fcb000)
libc.so.6 => /lib64/libc.so.6 (0x00007f98f2bfe000)
/lib64/ld-linux-x86-64.so.2 (0x00007f98f3c68000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f98f29fb000)
APR-util is also tiny, and is bound to a similar set of libraries, most notably
due to some very old legacy code, we hard bind the whole apr-util library to
expat:
[root@tools ~]# ls -al /usr/lib64/libaprutil-1.so.0.5.2
-rwxr-xr-x. 1 root root 172288 Jun 10 2014 /usr/lib64/libaprutil-1.so.0.5.2
[root@tools ~]# ldd /usr/lib64/libaprutil-1.so.0.5.2
linux-vdso.so.1 => (0x00007ffc0027f000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f35578cf000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f3557698000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f355746e000) <------
libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f35570af000)
libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007f3556e76000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3556c5a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3556a56000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3556689000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3557cfd000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f3556486000)
librt.so.1 => /lib64/librt.so.1 (0x00007f355627e000)
Now lets bring in the postgresql driver for the apr_dbd library:
[root@tools ~]# rpm -q -l apr-util-pgsql.x86_64
/usr/lib64/apr-util-1/apr_dbd_pgsql-1.so
/usr/lib64/apr-util-1/apr_dbd_pgsql.so
[root@tools ~]# ldd /usr/lib64/apr-util-1/apr_dbd_pgsql-1.so
linux-vdso.so.1 => (0x00007ffdf077f000)
libpq.so.5 => /lib64/libpq.so.5 (0x00007f66eb1d8000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f66eafbc000)
libc.so.6 => /lib64/libc.so.6 (0x00007f66eabef000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f66ea97d000) <—
openssl
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f66ea51c000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f66ea234000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f66ea030000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f66e9de3000)
libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f66e9b84000)
/lib64/ld-linux-x86-64.so.2 (0x00007f66eb60d000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f66e9951000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f66e974d000)
libz.so.1 => /lib64/libz.so.1 (0x00007f66e9537000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f66e9329000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f66e9125000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f66e8f0c000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f66e8cfd000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f66e8ae0000)
libssl3.so => /lib64/libssl3.so (0x00007f66e888e000) <— NSS
libsmime3.so => /lib64/libsmime3.so (0x00007f66e8667000)
libnss3.so => /lib64/libnss3.so (0x00007f66e833a000)
libnssutil3.so => /lib64/libnssutil3.so (0x00007f66e810b000)
libplds4.so => /lib64/libplds4.so (0x00007f66e7f07000)
libplc4.so => /lib64/libplc4.so (0x00007f66e7d02000)
libnspr4.so => /lib64/libnspr4.so (0x00007f66e7ac4000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f66e789d000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f66e7666000)
librt.so.1 => /lib64/librt.so.1 (0x00007f66e745e000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f66e71fc000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f66e6ff9000)
There is a lot going on. apr-util-pgsql links to libpq, which brings in all
sorts of libraries, including both NSS and openssl at the same time.
The DSO mechanism insulates our end users from this - if you don’t want
postgresql, you simply don’t dynamically load it and you’re not impacted. But
if you do need it, there it is.
Now, let’s bring in the apr-util-openssl driver for the apr_crypto library:
[root@tools ~]# rpm -q -l apr-util-openssl.x86_64
/usr/lib64/apr-util-1/apr_crypto_openssl-1.so
/usr/lib64/apr-util-1/apr_crypto_openssl.so
[root@tools ~]# ldd /usr/lib64/apr-util-1/apr_crypto_openssl-1.so
linux-vdso.so.1 => (0x00007ffcaa789000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007fedb74cd000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fedb706c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fedb6e50000)
libc.so.6 => /lib64/libc.so.6 (0x00007fedb6a83000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fedb6836000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fedb654e000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fedb634a000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fedb6117000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fedb5f13000)
libz.so.1 => /lib64/libz.so.1 (0x00007fedb5cfd000)
/lib64/ld-linux-x86-64.so.2 (0x00007fedb7944000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fedb5aef000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fedb58eb000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fedb56d2000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fedb54ab000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fedb5249000)
Again, there is a lot going on. Redhat users are going to be mighty peeved if
they install APR and in the process get an enormous list of transitive
libraries that they don’t want or need.
This shows the next problem: we’re trying to make changes to apr_util_openssl
that binds to openssl, but we’re completely ignoring apr_util_pgsql which also
binds to openssl, and apr_util_mysql which binds to openssl, etc etc etc.
Whatever changes we try to make to apr_crypto also need to be made to apr_dbd,
and apr_ldap, and possibly other libraries, otherwise we’re solving nothing.
>> Remember this is the Apache Portable Runtime, and currently there is
>> nothing portable about the PRNG implementation.
>
> Do you mean openssl isn't portable?
Yes.
Openssl is deprecated on MacOS, and is currently still stuck at v0.9.8 in High
Sierra with no plans for an upgrade:
Little-Net:~ minfrin$ ls -al /usr/lib/libssl.0.*
-rwxr-xr-x 1 root wheel 392912 Jul 4 07:57 /usr/lib/libssl.0.9.7.dylib
-rwxr-xr-x 1 root wheel 630144 Jul 4 07:57 /usr/lib/libssl.0.9.8.dylib
This is why we have commoncrypto.
Openssl is entirely missing on Windows. Sure, httpd builds typically package
it, but we’re not httpd, we’re APR.
> (BTW, I still struggle on how to do
> simple/run-this-cipher-with-this-key crypto with libnss, or even find
> a stream cipher with commoncrypto).
I struggled so you don’t have to. (To give credit where it is due, apr_crypto
was based largely on https://www.aleksey.com/xmlsec/)
A quick google for CHACHA support shows NSS has it in RHEL6/7 since here:
https://bugzilla.redhat.com/show_bug.cgi?id=1373158
On the Mac, I would stick to using their randomisation libraries:
https://developer.apple.com/documentation/security/randomization_services?language=objc
>> This needs to be changed to follow our existing convention.
>
> I think there isn't a single convention in APR, libxml2 is not dlopen()ed
> right?
There is a convention as described above, with expat/libxml2 being the
exception due to the age of the code.
Regards,
Graham
—
