SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Today is the official end of life for OpenSSL 1.1.1. I'm wondering what the path forward for Slackware 15.0 is.
It would seem increasingly unsafe to continue using OpenSSL 1.1.1 if it's not getting any more security updates, and a premium support contract is out of the question.
I'd rather not move to -current as during much of the year I have very little time to deal with breakage and need my machines to be as stable as possible, but perhaps that's the price of security.
Is it possible to upgrade to version 3.1.2 of OpenSSL and recompile all packages that depend on OpenSSL? Given that version 1.1.1 is still in -current alongside version 3.1.2, I'd guess that some packages aren't ready for v3 yet and wouldn't recompile.
Since months now, I install openssl-3.1 (in /opt/openssl3.1) and recompile against most of packages I really need like postfix/dovecot, proftpd, openssh, bind, php, curl, wget…
Before 15.0 was released, I did the same thing openssl-1.1.1 when 14.2 had openssl-1.0.2.
I'm mostly worried about openssh, postfix, wget, Thunderbird, and my web browsers. I don't know much about Thunderbird and the web browsers as I've not looked at their source. Perhaps they come with their own SSL libraries--I don't know. I'm glad to know that you've been able to recompile the first three with OpenSSL 3.1. I'd hate to have my ssh servers or my connections to retirement accounts compromised. It could be catastrophic.
I just want to chime in, my smxi.org web hoster finally dropped all SSL 1 support, and now connections attempting to connect with SSL 1 only are rejected. With an https site, that means no access at all. That hoster is quite conservative, and probably maintained this support longer than most do.
I realized this yesterday when I was testing inxi's self updater on a very old system on an old laptop, Debian Lenny in this case, which I think is roughly 2008 vintage, and for the first time, the wget/curl connection, all connections in fact, to the website failed. Older systems of course are even less likely to be able to do this type of remote access.
While I hacked out a server side solution using FTP instead along with an inxi based new updater option using ftp connection, this highlighted the issue with using SSL 1 on the operating system, I think for example github has been rejecting SSL 1 for much longer, not sure.
Even this is a short term solution, because if sftp is enforced, then that will fail too.
I had not really thought about what a problem a remote system rejecting flat out an SSL 1 request might cause because I'd been able to work around it for years, but it's a real issue if the system has to talk to the modern internet in any real way.
Does anyone know which programs are compiled for 3.x in -current?
You can check it yourself if you have -current:
Code:
#!/bin/sh
[ $# -lt 1 ] && echo "Usage, for example: " $0 "'libcrypto.so.3|libssl.so.3'" && exit 1
cd /var/adm/packages
for pkg in *; do
( cd /
while read line; do
[ "$line" = "FILE LIST:" ] && break
done
while read f; do
[ -x "$f" -a -f "$f" -a -r "$f" ] && objdump -p "$f" 2>/dev/null|grep NEEDED|grep -Eq "$1" && echo "$pkg": /"$f"
done
) < $pkg
done
(I don't have a complete installation myself, so I don't give the output here.) But the only packages linking to the old openssl11 seem to be python2 and python2-module-collection. You can run the script in 15.0 and look for references to 'libcrypto.so.1.1|libssl.so.1.1' to get the idea of which programs are linked to openssl-3 in -current.
Last edited by Petri Kaukasoina; 09-13-2023 at 01:28 AM.
I just want to chime in, my smxi.org web hoster finally dropped all SSL 1 support, and now connections attempting to connect with SSL 1 only are rejected. With an https site, that means no access at all. That hoster is quite conservative, and probably maintained this support longer than most do.
I realized this yesterday when I was testing inxi's self updater on a very old system on an old laptop, Debian Lenny in this case, which I think is roughly 2008 vintage, and for the first time, the wget/curl connection, all connections in fact, to the website failed. Older systems of course are even less likely to be able to do this type of remote access.
While I hacked out a server side solution using FTP instead along with an inxi based new updater option using ftp connection, this highlighted the issue with using SSL 1 on the operating system, I think for example github has been rejecting SSL 1 for much longer, not sure.
Even this is a short term solution, because if sftp is enforced, then that will fail too.
I had not really thought about what a problem a remote system rejecting flat out an SSL 1 request might cause because I'd been able to work around it for years, but it's a real issue if the system has to talk to the modern internet in any real way.
SSL 1 has nothing to do with OpenSSL 1.1
SSL 1 is a protocol and version name which is very old and unsecure.
OpenSSL 1.1 is a version of the OpenSSL library which don't follow protocols versioning.
OpenSSL 1.1 has support for latest SSL or TLS versions. But it will be no longer maintained in favor of OpenSSL 3.
I never (ever) ask this but has Pat mentioned how close 15.1 is?
Elsewhere in the forum Pat hinted or teased, but not committed, that perhaps sooner rather than later. At least GRUB needs to be fully merged and tested and there are yet to be related announcements in the change log. After that event a fair SWAG might be that release could be soon thereafter, but guessing release dates is always one of the great mindless but enjoyable past times of being a Slackware user.
Related to this thread, once every third blue moon or so Pat sometimes backports "big" patches to a stable release. Maybe he'll do that with openssl and 15.0, maybe not. Another speculation is he might patch openssl in 15.0 on his own until 15.1 is released. Another SWAG is he would instead focus on releasing 15.1 so those who are affected by the SSL EOL have an option. So much fun trying to outguess Pat!
So as the old adage goes, "Patience Grasshopper." Unlike from 14.2 to 15.0, the 15.0 to 15.1 changes are nowhere as dramatic or Sisyphean. Updating to 15.1 should be a nice return to the old days of being boring.
My unimportant n=1 hope is 15.1 is released with KDE 5.27.x rather than KDE 6.0.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
