Security related fixed packages
There are times when there is a flow in security and some packages are needed to be rebuild with the security related patches. This section tries to answer questions related to this topic.
 | SuSE's policy is to patch existing version numbers as not to break any dependancies. |
You may want to subscribe to SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to suse-security-announce-subscribe@suse.com
Peter Poeml
Sometimes on the SuSE list folks express doubts whether a package contains a certain fix or not. Even if the security announcements say the packages are not vulnerable, they want to know for sure. Looking at the version number of the package is most likely not enough to be sure... but how then? How to look "into" the packages?
I thought I'd write up a short howto and post it here.
How to find out what HAS been changed:
get the original source RPM as distributed on the CDs ("zq" or "src" directory)
get the "fixed" package (see the security announcement, it contains the link to where to find it.)
compare the changelogs of the packages:
rpm -qp --changelog /path/to/old.rpm > /tmp/old.changes rpm -qp --changelog /path/to/new.rpm > /tmp/new.changes diff -u /tmp/old.changes /tmp/new.changes | grep "^+"
compare the file lists (just for an overview):
This step would very likely show you that a patch file that has been added./usr/lib/rpm/rpmdiff /path/to/old.rpm /path/to/new.rpm
to look further, unpack the source RPMs:
mkdir old; ( cd old; rpm2cpio /path/to/old.rpm | cpio -i --make-directories ) mkdir new; ( cd new; rpm2cpio /path/to/new.rpm | cpio -i --make-directories )compare the two directories:
ordiff -uNr old new | less
if you like it colorful. Or, pipe it into diffstat, or print it out via pdiff :-)diff -uNr old new | view - -c "syntax on"
How to find out what SHOULD have been changed:
get the most recent sources (i.e. the fixed version) of, for example, openssl.
get the second most recent sources (the vulnerable version).
untar both of them.
read and compare the ChangeLog or CHANGES files (or a similar file).
run a recursive diff about the two source directories to review the changes.
Taking this even further, to really verify that the vulnerability is gone, you need a testcase (an exploit).
Anyway, your picture about the packages should be complete by then, and all your doubts hopefully gone.
For remaining questions you could contact this list (<suse-security@suse.com>).
In case of serious concerns you should contact the SuSE Security Team directly, writing to <security@suse.de>.