Hello,

and Merry Christmas. Today I upgrade to current tree and after restrarting samba package got error:

root@www:~# sh /etc/rc.d/rc.samba start
Starting Samba: /usr/sbin/smbd -D
/usr/sbin/smbd: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
/usr/sbin/nmbd -D


Quick worked fix is until new in tree:
ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

Works fine here

Yes,
package 4.7.3 work, 4.7.4 does not.

# pkg_info -s samba
samba-4.7.3-x86_64-1

# ldd /usr/sbin/smbd | grep crypt
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f6bd80c5000)
libcrypto.so.1 => /lib64/libcrypto.so.1 (0x00007f6bd510a000)
libhcrypto-samba4.so.5 => /usr/lib64/libhcrypto-samba4.so.5 (0x00007f6bd411b000)


# slackpkg upgrade
# slackpkg install-new
# slackpkg upgrade-all
# ldconfig
# pkg_info -s samba
samba-4.7.4-x86_64-1

# ldd /usr/sbin/smbd | grep crypt
libcrypto.so.1.1 => not found
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f09cc717000)
libcrypto.so.1 => /lib64/libcrypto.so.1 (0x00007f09c975c000)
libhcrypto-samba4.so.5 => /usr/lib64/libhcrypto-samba4.so.5 (0x00007f09c876d000)

x86 seems to work fine here, so i think it only happened on x86_64 since i can reproduce the same thing on my x86_64 machine

and it seems not only samba is affected, but also vorbis-tools and moc.

i think, it's compiled with openssl-1.1.0

yes, looking at the version, it seems Patrick is testing openssl 1.1.x

vorbis-tools-1.4.0-x86_64-2 and moc-2.5.2-x86_64-2 are also affected.

It's Christmas, we will not quibble

1 members found this post helpful.

Hell no! Even if it's not christmas, slackware packages are more or less always presents.

I think they changed the INSTALL_PREFIX functionality in that. I was wondering why there weren't any libraries in the test package.

Yes, I am looking into the new openssl (how did you know lol), but first we'll fix these mislinked packages. The new openssl will need a hundred recompiles more or less. The ABI is not at all backward compatible, and everything using libssl or libcrypto is going to need to be upgraded or rebuilt.

3 members found this post helpful.

Given that there are already disruptive ABI changes, maybe its worth (re)considering libressl? It might reduce this instability in the future while providing better security, but I'm not sure how many of the smaller details may or may not make this practical?

LibreSSL does not seem to have a lot of traction outside the BSDs. Void Linux uses it, but they are a rolling release and can recompile everything all the time - LibreSSL is not exactly focused on LTS releases (yet?), which may make it less useful for Slackware's purposes.
https://www.libressl.org/releases.html

Also, LibreSSL's 'just' (actually a massive achievement) a cleaned-up version of OpenSSL 1.0.x.
https://github.com/libressl-portable...y-with-openssl
There is a 'risk' important software will move on to 1.1 to the extent of leaving 1.0 (either in its OpenSSL or LibreSSL form) unsupported or nearly so (lots of patches needed).

The people behind LibreSSL seem unhappy with the 1.0->1.1 change too
http://openbsd-archive.7691.n7.nabbl...-td310468.html
and they appear reluctant to make LibreSSL support 1.1 anytime soon, but all they would be able to do to put their foot down, if they would want, is to not yet co-operate with efforts to make OpenSSH (which they are also involved with) 1.1-compatible.
https://bugs.debian.org/cgi-bin/bugr...?bug=828475#70

I like LibreSSL a lot but OpenSSL 1.1 is probably the safer bet at the moment, unfortunately...

1 members found this post helpful.

gildbg, have you tried the most recent current?

Exactly. Also, OpenSSL also had an injection of funding and development resource (from some of the businesses that depend on it) after the scares last year, with the aim of improving the strength of the product.

While libressl was often not affected or already fixed.
https://en.wikipedia.org/wiki/LibreS...ulnerabilities

The point about API compatibility is good as its still yet to be seen how this plays out.