LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-18-2015, 04:42 PM   #1
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 587

Rep: Reputation: 423Reputation: 423Reputation: 423Reputation: 423Reputation: 423
Managing the aaa_elflibs package


Hello

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.

I have updated the document and it has been reviewed by Patrick.
http://www.slackware.com/~mozes/docs/aaa_elflibs.txt

Last edited by drmozes; 03-18-2015 at 04:44 PM.
 
Old 03-18-2015, 04:57 PM   #2
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,408
Blog Entries: 15

Rep: Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982
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?

Last edited by ReaperX7; 03-18-2015 at 04:59 PM.
 
Old 03-18-2015, 05:34 PM   #3
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,366

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
Quote:
Originally Posted by ReaperX7 View Post
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).
 
4 members found this post helpful.
Old 03-18-2015, 10:56 PM   #4
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,408
Blog Entries: 15

Rep: Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982Reputation: 1982
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.
 
Old 03-19-2015, 05:05 AM   #5
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Posts: 7,761

Rep: Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687Reputation: 2687
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 06:36 AM.
 
3 members found this post helpful.
Old 03-20-2015, 12:24 PM   #6
the3dfxdude
Member
 
Registered: May 2007
Posts: 519

Rep: Reputation: 191Reputation: 191
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 10:18 AM.
 
1 members found this post helpful.
Old 03-21-2015, 04:12 AM   #7
genss
Member
 
Registered: Nov 2013
Posts: 739

Rep: Reputation: Disabled
the libraries in aaa_elflibs are from other packages
libz, libncurses, libelf, etc.
 
Old 03-21-2015, 08:04 AM   #8
GazL
Senior Member
 
Registered: May 2008
Posts: 4,480
Blog Entries: 7

Rep: Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958Reputation: 1958
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.
 
Old 03-21-2015, 10:32 AM   #9
the3dfxdude
Member
 
Registered: May 2007
Posts: 519

Rep: Reputation: 191Reputation: 191
Quote:
Originally Posted by genss View Post
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.
 
Old 03-21-2015, 11:05 AM   #10
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,128
Blog Entries: 4

Rep: Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548Reputation: 1548
Quote:
Originally Posted by the3dfxdude View Post
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.

aaa_elflibs-14.1-x86_64-3 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.0.1-x86_64-1 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.5-x86_64-1_slack14.1 contains usr/lib64/libfreetype.so.6.11.4

Before the patch:
Code:
lrwxrwxrwx 1 root root     21 Dec 11  2013 /usr/lib64/libfreetype.so -> libfreetype.so.6.10.2
lrwxrwxrwx 1 root root     21 Dec 11  2013 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2
After the patch:
Code:
lrwxrwxrwx 1 root root     21 Jan 29 10:12 /usr/lib64/libfreetype.so -> libfreetype.so.6.11.4
lrwxrwxrwx 1 root root     21 Jan 29 10:12 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.11.4
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 614576 Jan 13 22:22 /usr/lib64/libfreetype.so.6.11.4
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.

Last edited by 55020; 03-21-2015 at 11:07 AM.
 
2 members found this post helpful.
Old 03-21-2015, 11:49 AM   #11
the3dfxdude
Member
 
Registered: May 2007
Posts: 519

Rep: Reputation: 191Reputation: 191
Quote:
Originally Posted by 55020 View Post
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.

aaa_elflibs-14.1-x86_64-3 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.0.1-x86_64-1 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.5-x86_64-1_slack14.1 contains usr/lib64/libfreetype.so.6.11.4

Before the patch:
Code:
lrwxrwxrwx 1 root root     21 Dec 11  2013 /usr/lib64/libfreetype.so -> libfreetype.so.6.10.2
lrwxrwxrwx 1 root root     21 Dec 11  2013 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2
After the patch:
Code:
lrwxrwxrwx 1 root root     21 Jan 29 10:12 /usr/lib64/libfreetype.so -> libfreetype.so.6.11.4
lrwxrwxrwx 1 root root     21 Jan 29 10:12 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.11.4
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 614576 Jan 13 22:22 /usr/lib64/libfreetype.so.6.11.4
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.
 
Old 03-21-2015, 12:45 PM   #12
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,366

Rep: Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835Reputation: 835
Quote:
Originally Posted by 55020 View Post
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 View Post
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.
 
Old 03-22-2015, 01:57 PM   #13
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 587

Original Poster
Rep: Reputation: 423Reputation: 423Reputation: 423Reputation: 423Reputation: 423
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.
 
Old 03-22-2015, 06:07 PM   #14
the3dfxdude
Member
 
Registered: May 2007
Posts: 519

Rep: Reputation: 191Reputation: 191
Thanks for the update.
 
Old 12-23-2015, 02:59 AM   #15
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,237

Rep: Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725
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 :-)
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Strategies for managing very frequent Fedora package updates? penyuan Fedora 5 08-23-2014 04:06 AM
First release of compat32pkg. A simple tool for managing package to format compat32.. phenixia2003 Slackware 12 09-24-2010 08:02 AM
Problem in package managing through GUI zombiechum Linux - Networking 1 11-04-2009 06:50 PM
package managing questions for newbie wakeboarder3780 Slackware 9 04-25-2006 08:13 PM
Slackware package managing system moses Slackware 11 01-08-2003 02:55 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:54 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration