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.
Apparently there is some confusion around upgrading the aaa_elflibs package.
I had collated notes from Patrick about 10 years ago, which were correct at the time but the use of the aaa_elflibs package has changed since then. The package now can and should now be upgraded at certain points.
Everything but the directory package can be updated. I usually snag aaa_elflibs myself without penalty. It's aaa_base you NEVER EVER touch... which brings a good question, why is aaa_base even version controlled at all?
Everything but the directory package can be updated. I usually snag aaa_elflibs myself without penalty. It's aaa_base you NEVER EVER touch... which brings a good question, why is aaa_base even version controlled at all?
aaa_base mostly extracts empty directories over the existing filesystem, which won't clobber anything but will reset permissions to their defaults (which, unless you've been mucking things up, shouldn't be any different anyway). It may include new directories that did not exist in a previous version of Slackware. It includes /etc/os-release and /etc/slackware-version, which should always match the version of Slackware you are running or scripts that depend on this information may choke (slackpkg parses this but I'm not sure if it actually uses it, but third-party scripts like sbopkg do).
Thus, I must conclude that, contrary to your advice, aaa_base should *always* be updated following very much the same instructions as for aaa_elflibs in the OP -- do not upgrade aaa_base from -current if you are and will continue to be running a stable release because it may throw /etc/slackware-version out of whack, but do upgrade from version to version and keep up to date in -current (not that this will have much of an effect until the version gets bumped in an rc).
I'm surprised that this package doesn't receive something as trivial as a patch if you run -Current, rather than a set release number if you run RTM. A patch ran against the system could add any missing directories with sed arguments made for any specific files that check for version controls, and updates as necessary using if/else. That wouldn't reset permissions, but it would keep aaa_base up-to-date without touching anything heavily. Plus, wouldn't it better better to have aaa_base listed as a dated file rather than a version file such as aaa_base-20150317-x86_64-1.txz? I don't see where new directories would be worrisome as most packages create directories as needed themselves.
This thread is intended to provide an information about aaa_elflibs, useful for people who upgrade to -current and follow its evolution. It would save readers' time to stick to that topic.
Last edited by Didier Spaier; 03-19-2015 at 05:36 AM.
So I came back to this again, even though for years, I understood the package, realizing I do not remember any instance of a security update for the aaa_elflibs. Does something need to be said here?
Basically, on "Stable Slackware releases", security updates would be similar but slightly variant of drmozes rules. Meaning, since the aaa_elflibs package is not updated, but the actual library package is, then the user must update the actual library package, and never reinstall aaa_elflibs. An example I found of this is that Slackware 8.1 the pcre package had a patch version, but then elflibs as it was then called was not updated. So if sticking with 8.1, just make sure you never reinstall elflibs--no big deal. That covers part of it. If on -current, following the rules of the "rolling" -current, then you are fine there too for security updates.
But what I am wondering is what happens for stable slackware if there is a security vulnerability in an superceded library version, that is still provided with aaa_elflibs for compatibility reasons? If I can remember a point which this happened, I would go with that as an example, but I can't. My guess is that if aaa_elflibs needs a patch rolled out, the libs will have to be snapshot to the latest in the stable version, and at that time, if aaa_elflibs is upgraded to or installed first, then it is okay. Same as -current really.
Last edited by the3dfxdude; 03-21-2015 at 09:18 AM.
It's possible/likely that any legacy libraries that are included only in aaa_elflibs are not even supported upstream anymore, which may be why we never see updates show up.
The implications of aaa_elflib are something that those who don't do 'Full' installs might want to keep in mind: you might end up missing an update should a package you don't have installed show up in patches/.
Interesting observations 3dfx. I hadn't previously considered any of this.
the libraries in aaa_elflibs are from other packages
libz, libncurses, libelf, etc.
Yes, that was my first part of my point. My general point is that more might need to be said about how security updates are handled.
1) On stable slackware, aaa_elflibs should never be reinstalled, otherwise you might get vulnerable libraries back on the system, and a false impression of the patch still installed.
2) If a patch to aaa_elflibs had to be released (assuming upstream has not completely abandoned or Pat applies a contributed patch), then it would have to be updated first, in order, and then follow stable rules again. This is my guess, since I do not remember an example.
But what I am wondering is what happens for stable slackware if there is a security vulnerability in an superceded library version, that is still provided with aaa_elflibs for compatibility reasons? If I can remember a point which this happened, I would go with that as an example
With dynamic libraries, executables should not use the exact library name; they should use the major version of the library name, which is symlinked to the exact library. When a Slackware a package is installed or updated, the doinst.sh will create the right symlinks.
The example you are looking for is freetype; libfreetype is in the original aaa_elflibs_14.1, and freetype got a security patch on 17-Jan-2015.
In this scenario, any executable that used libfreetype.so.6.10.2 instead of libfreetype.so.6 might as well be statically linked, and it would have the same security problem that a statically linked executable would have. And that is why there should not be any such executables. However, by keeping the old file libfreetype.so.6.10.2, Slackware ensures that any such executables are not broken and will still work, even though they don't benefit from the patch. And that is why the aaa_elflibs package does not get patched.
With dynamic libraries, executables should not use the exact library name; they should use the major version of the library name, which is symlinked to the exact library. When a Slackware a package is installed or updated, the doinst.sh will create the right symlinks.
The example you are looking for is freetype; libfreetype is in the original aaa_elflibs_14.1, and freetype got a security patch on 17-Jan-2015.
In this scenario, any executable that used libfreetype.so.6.10.2 instead of libfreetype.so.6 might as well be statically linked, and it would have the same security problem that a statically linked executable would have. And that is why there should not be any such executables. However, by keeping the old file libfreetype.so.6.10.2, Slackware ensures that any such executables are not broken and will still work, even though they don't benefit from the patch. And that is why the aaa_elflibs package does not get patched.
Well that is not what I am looking at. It is a interesting scenario I have seen, but not my concern.
So you point out a trivial case, that works in the described rules no matter what happens since the files are differently named. If you look at the pcre patch case from Slackware 8.1, it kept the exact same file version number before and after the patch. This means that a reinstall of elflibs would overwrite the exact file, causing an unintended downgrade.
In my other question, my concern is with libs that have a major number version change, and use specially named libs. An example of these are jpeg6, png12, db-3, etc that their obsolete versions were kept around for some time after the specific lib package was dropped.
In this scenario, any executable that used libfreetype.so.6.10.2 instead of libfreetype.so.6 might as well be statically linked, and it would have the same security problem that a statically linked executable would have. And that is why there should not be any such executables. However, by keeping the old file libfreetype.so.6.10.2, Slackware ensures that any such executables are not broken and will still work, even though they don't benefit from the patch. And that is why the aaa_elflibs package does not get patched.
Quote:
Originally Posted by GazL
The implications of aaa_elflib are something that those who don't do 'Full' installs might want to keep in mind: you might end up missing an update should a package you don't have installed show up in patches/.
If you don't have the freetype package installed, the old vulnerable library will still be installed on the system (thanks to aaa_elflibs) and a patched version will never be installed. So as GazL points out, unless you have a full install, the dynamic nature of library versioning won't matter -- you don't get a patch to aaa_elflibs and therefore you will remain vulnerable. A proper solution would be to rebuild aaa_elflibs, keeping the old freetype version around but also including the new one. Then your description would be appropriate for both full installs and partial installs. As of now, this only happens when a new stable version is released (or once in a while when necessary in -current), but never during the lifetime of a stable release.
I have updated the doc with how to manage it from a security point of view. If you do a full installation of Slackware then the contents of that package will be overwritten by upgrading to a newer patch package of that owns an affected library.
The remaining 7 (at present) libraries would not receive any security updates since they are only provided by aaa_elflibs. In this case if you were really concerned, you might want to determine whether they're still needed and move them out of the way.
It's now worth noting that aaa_elflibs is no longer blacklisted in the default slackpkg configuration, so hopefully this entire post will slide into irrelevance once 14.2 is released :-)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.