How long does a given version of Slackware have security support?
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.
How long does a given version of Slackware have security support?
I was wondering what is the policy of Slackware.inc regarding old versions of Slackware and how long are these "obsolete" versions supposed to have security support.
I have made a quick search in the WWW with Teoma, but the most useful thing I have found is that Slackware 8.1 (2002) still has security updates. That makes for 9 years of support (take that, Red Hat!). However, this is not an ultimate answer.
Has Slackware.inc made an official claim in this regard? If I run Slackware 13.37 today, can I know when support for it will be dropped? Yeah, sure the recommendation is to always update to the last stable release, but many times updating for the shake of updating is not a good idea
Last edited by BlackRider; 08-18-2011 at 05:40 AM.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Pretty sure, i read on Linux Questions, not so long ago that support up to 8.1 is still supported
I dont think Pat would just drop support for his baby any time soon. Dont feel like you have to be at 13.37. I'm at 13.1 and my university (50,000 + students) have servers that run on 13.0 !!!
Security updates will be provided for 13.37 for a very very long time. Dont stress, and if you dont wanna move from 13.37 to whatever the next 13.** will be. Stick with 13.37 and just update security patches with slackpkg. Easy Peasy
Thank Pat for this
P.S sign up to the Slackware security email list... helps me
... think the links on the Slackware site
It's probably best to think of Slackware's security policy as 'best endeavours'.
If Pat becomes aware of a security issue (and occasionally you do have to prod him because he misses stuff ) and it's easy to patch then he tends to make it available for every version he can. However, if the patch would take too much effort to apply or he considers it too intrusive then he might decide it's better not to apply it.
You have to remember that Slackware is a small-scale operation and unlike Redhat Pat doesn't have a team of programmers sitting there back-porting bug-fixes. Anyone who is really serious about security will probably be better off with a distro that can throw more resource at the issue
This is not a criticism, it's just the way it is, and sometimes you may find you need to, er... take-up some of the Slack yourself.
(Sorry 'bout the pun)
New bind packages are available for Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2,
11.0, 12.0, 12.1, 12.2, 13.0, 13.1, 13.37, and -current to fix security issues.
Here are the details from the Slackware 13.37 ChangeLog:
+--------------------------+
patches/packages/bind-9.7.4-i486-1_slack13.37.txz: Upgraded.
This BIND update addresses a couple of security issues:
* named, set up to be a caching resolver, is vulnerable to a user
querying a domain with very large resource record sets (RRSets)
when trying to negatively cache the response. Due to an off-by-one
error, caching the response could cause named to crash. [RT #24650]
[CVE-2011-1910]
* Change #2912 (see CHANGES) exposed a latent bug in the DNS message
processing code that could allow certain UPDATE requests to crash
named. [RT #24777] [CVE-2011-2464]
For more information, see: http://cve.mitre.org/cgi-bin/cvename...=CVE-2011-1910 http://cve.mitre.org/cgi-bin/cvename...=CVE-2011-2464
(* Security fix *)
+--------------------------+
Where to find the new packages:
+-----------------------------+
Thanks to the friendly folks at the OSU Open Source Lab
(http://osuosl.org) for donating FTP and rsync hosting
to the Slackware project! :-)
Also see the "Get Slack" section on http://slackware.com for
additional mirror sites near you.
I dont think Pat would just drop support for his baby any time soon. Dont feel like you have to be at 13.37. I'm at 13.1 and my university (50,000 + students) have servers that run on 13.0 !!!
I am not the kind of guy who is upgrading whenever he cans. If it were not for some hardware issues, I would still use Debian Lenny until security support came to an end. The only reason why I am using Slackware is because the current Debian release is a regression from what Debian 5 was. Chances are that I will run Slackware 13.37 in this machine until the PC falls apart or I update the hardware itself.
This does not mean that I won't subscribe to test every release on a testing partition. Want a piece of advise? Always dual-boot. If you break your main OS, you will have somewhere to fallback.
Quote:
You have to remember that Slackware is a small-scale operation and unlike Redhat Pat doesn't have a team of programmers sitting there back-porting bug-fixes. Anyone who is really serious about security will probably be better off with a distro that can throw more resource at the issue
Good to know. I already suspected that security was not a priority for Slackware.inc because some details, like the X server listening for incoming tcp connections by default. Well, it is still better than some other distributions that have not security service at all.
As I see it, the problem with security in Slackware is not the main components themselves, but the third party software you install. If you install stuff from SlackBuilds.org and a day later upstream authors publish a security fix, then you surely will have to wait until the SlackBuild is updated or update it by yourself... and this is if we suppose that we know that upstream has released this security fix...
Quote:
P.S sign up to the Slackware security email list.
I did that just after I finished mi install :-)
The main question, however, remains opened. It is not that I have high security requirements -in fact, I don't have them even when I use to take measures like I was holding the launch codes of the nuclear warheads of a powerful country. I think that it is a reasonable question: if I install this thing now, how long will it be seriously supported? I mean, I don't think Slackware.inc would start backporting security fixes to Slackware 1.0 even if they could do it easily. There is a limit to the number of Slackware versions that can be supported at the same time.
By the way, is there any centralized and trustworthy site that tracks security exploits and patches? Just curiosity.
I am not the kind of guy who is upgrading whenever he cans. If it were not for some hardware issues, I would still use Debian Lenny until security support came to an end. The only reason why I am using Slackware is because the current Debian release is a regression from what Debian 5 was. Chances are that I will run Slackware 13.37 in this machine until the PC falls apart or I update the hardware itself.
This does not mean that I won't subscribe to test every release on a testing partition. Want a piece of advise? Always dual-boot. If you break your main OS, you will have somewhere to fallback.
Good to know. I already suspected that security was not a priority for Slackware.inc because some details, like the X server listening for incoming tcp connections by default. Well, it is still better than some other distributions that have not security service at all.
As I see it, the problem with security in Slackware is not the main components themselves, but the third party software you install. If you install stuff from SlackBuilds.org and a day later upstream authors publish a security fix, then you surely will have to wait until the SlackBuild is updated or update it by yourself... and this is if we suppose that we know that upstream has released this security fix...
I did that just after I finished mi install :-)
The main question, however, remains opened. It is not that I have high security requirements -in fact, I don't have them even when I use to take measures like I was holding the launch codes of the nuclear warheads of a powerful country. I think that it is a reasonable question: if I install this thing now, how long will it be seriously supported? I mean, I don't think Slackware.inc would start backporting security fixes to Slackware 1.0 even if they could do it easily. There is a limit to the number of Slackware versions that can be supported at the same time.
By the way, is there any centralized and trustworthy site that tracks security exploits and patches? Just curiosity.
It is up to the end user to keep up with any 3rd party software security patches. This is the case for any OS.
Slackware will patch the base OS. Anything not included in the base than is consider 3rd party and it will be up to you to update. I keep up with my patches on my own of those pkgs that I install manually via slackbuilds or just compiling... I keep a list and track on a monthly basis... Why does it matter what versions they go back to support? if you are concern that 8 month from now they will stop releasing patches or deprecate the version like ubuntu or fedora will than dont because Slackware versions stick for a while. I am not sure what you mean by seriously supported? I am sure is not a joke to Pat to release patches for hes OS Slackware even to 8.1
I already suspected that security was not a priority for Slackware.inc because some details, like the X server listening for incoming tcp connections by default.
"I already suspected that security was not a priority for Slackware.inc because some details, like the X server listening for incoming tcp connections by default."
Maybe you should read a bit more before you bag Slackware mate. If you cant handle Slackware than move on. Slackware gives you a blank canvas to work on. Its not a whole install/ready to go thing(if you want that than try...... WINDOWS!!!
Its up to you to make your machine as secure as possible, not Pats, or anyone else on the Slack team. It doesn't matter if you run RedHat, which has Programmers etc working 24/7...... if someone wants to get into your system, trust me, they will !
Its up to YOU to protect your system no matter what operating system your running. No OS is going to tell you "hey BlackRider, i think you system is vulnerable, Hey BlackRider i think you've got a rootkit, hey BlackRider theres some program running on port (blah) that listening for some unknown service called NC ". Its up to you to always be in the "know" which new exploits and techniques may compromise or give unwilling information about your system to crackers.
PacketStorm
&
Exploit database (if you can read code)
if I install this thing now, how long will it be seriously supported? .
It's not an easy question to answer. Take a look at the latest release: Unless you've taken some action of your own you'll still be running kernel 2.6.37.6 for which upstream security bug provision has already ceased. In fact it ceased somewhere around the time 13.37 actually came out. So if you take a hard-line, black & white stance, you could argue that: as Slackware doesn't have a kernel team back-porting fixes, even the latest release can already be considered as 'unsupported' - at least in-part. Of course, in the real world everything is shades of grey and it's not quite that simple. If a really significant issue came up, then I'm sure Pat would bump the stock kernel, but it's clear that he puts more value on stability than minor security issues, at least when it comes to the kernel.
Being one of the tin-foil hat brigade, I don't share this view and find it a little too conservative, But while I don't share it, I do understand it.
Oh, as for keeping an eye on things. I tend to look at the daily security reports on lwn.net, see what the other distro's are patching and if after reading the CVE it seems like something that's applicable to Slackware, and Pat doesn't provide it in patches/ I do my own local updates until he does.
At the moment I have 3:fairly recent ones.
/var/log/packages/dbus-1.4.14-x86_64-1_patch13.37
/var/log/packages/freetype-2.4.6-x86_64-1_patch13.37
/var/log/packages/libXfont-1.4.4-x86_64-1_patch13.37
Well, I use to compile my own kernels and forget about stock ones, so this is less a matter for me, but I get the point.
Mr. brianL, I already knew about sbopkg. The problem with slackbuids is that there is no way to ensure that the builds they post have the latest fixes. I has been recently posted in the mailing list that the clamav version is very outdated, for example, and that the script was not "so easy" to make work with the last version of clamav. OK, I have a brain and I can build this software by myself (it is what I did), but sbopkg would install the old version that still remains in SlackBuild.org. I guess this can happen with many other pieces of software.
Also, my claim about third party software is still valid. I have never said that someone else is responsible of what I install from outside the official DVD. The fact, however, is that with Slackware I end installing more external software that with any other distribution. In Debian, I had four self-made packages. In Slackware, I have about twenty. I even use to take the source for some official packages and recompile it to fit my needs. This means that there are 20 packages that won't have security support unless I provide it by myself, but this is something I already knew when I did install them.
Thanks for the links. I am having a look at them right now.
clamav is a special case for slackbuilds.org, because it's without maintainer at the moment: in every other case, best practice should be to contact the maintainer if you spot some security fixes.
To avoid sbopkg updating your custom packages, have a look at this Chess' post.
Good to know. I already suspected that security was not a priority for Slackware.inc because some details, like the X server listening for incoming tcp connections by default. Well, it is still better than some other distributions that have not security service at all.
Actually, security is a major priority, but you have to understand the approach that we take. Slackware is not the home for abandoned software. If upstream doesn't care to create security fixes, we're not likely to. If security is neglected by a given project, we're likely to drop it from Slackware. But, that's not always possible either.
In the case of the X server, perhaps someone might ask X.Org why that's the default? If they change it, then it won't be like that in Slackware. Also, consider that a lot of CVEs that are published are for rather low level issues. I can't count the number of times there was a CVE for a possible but unlikely issue like a denial of service, and the "fix" introduced a much more serious problem that was more likely to cause a denial of service than the originally reported bug.
I'm also pretty careful about not futzing with stuff needlessly, and this leads to better security than if I were to be absorbing all kinds of feature addition or other patches that aren't from upstream. No need to be changing the key generation in OpenSSL to screw up the salt...
I'm also pretty careful about not futzing with stuff needlessly, and this leads to better security than if I were to be absorbing all kinds of feature addition or other patches that aren't from upstream. No need to be changing the key generation in OpenSSL to screw up the salt...
It looks like Debian won't set itself free from this damnation. The OpenSSL issue will be brought up to any security related discussion, it seems :-)
This thread is perpetuating itself while arriving nowhere. That is not to say it is not interesting or useful, but my mind is set up in stubborn_draft_horse_mode and it forces me to walk towards my objective without straying apart from my path.
I will make the same question with other words.
Which criteria dictated that Slackware < 8.1 is not worth more security fixes, while Slackware => 8.1 is still supported?
Mozilla seems to be throwing a monkey wrench into things, though. I can't get the latest Seamonkey to build on Slackware 13.1. It requires a newer version of Cairo than what comes with 13.1.
I think that upgrading Cairo would require rebuilding Firefox and Thunderbird too.
For that matter, while new versions of Firefox and Thunderbird are making it into the -current branch, I haven't seen them in the older versions of the stable branch. Again, I think this is less of an issue because Firefox 3.6 and Thunderbird 3.1 are still supported.
Still, it would be great if the latest versions of those three packages -- with all the security updates -- would be available for older versions of Slackware.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
) and it's easy to patch then he tends to make it available for every version he can. However, if the patch would take too much effort to apply or he considers it too intrusive then he might decide it's better not to apply it.
