linux-ext4 - Re: libcom_err DSO version bump needed for 1.42?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Aug 2012 21:47:35 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"Brian J. Murrell" <brian@...erlinx.bc.ca>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: libcom_err DSO version bump needed for 1.42?

On Wed, Aug 15, 2012 at 05:48:12PM -0400, Brian J. Murrell wrote:
> I noticed when trying to upgrade my e2fsprogs RPM set from a 1.41.12ish
> release to a 1.42.3ish release only e2fsprogs and e2fsprogs-libs got
> upgraded and libcom_err didn't get upgraded despite there being ABI
> differences between 1.41.12 and 1.42.3.  This results in the following
> type of error:
> 
> # e2fsck
> e2fsck: symbol lookup error: e2fsck: undefined symbol: set_com_err_gettext
....
> 
> Since this addition introduces an ABI incompatibility in libcom_err,
> isn't the process supposed to be to increase the SO's version so that
> the tools find the proper version of the library and also so that it
> gets upgraded accordingly by RPM with it's autoprovides/requires bits?

There's a distinction which needs to be made between adding a new
symbol to a DSO, and making an incompatible chnage to the ABI of an
existing symbol of a DSO.  The former doesn't break any existing
programs (although you need to make sure you have a sufficiently new
version of the library for executables which use the newer symbols).
The latter does break previously existing programs that were linked
against the DSO.

Normally, we only bump the SO version in the latter case.

It is indeed up to packaging systems to do the right thing vis-a-vis
having the correct dependencies in their packages.  Debian/dpkg does
this automatically.  Note the current set of dependencies for the
e2fsprogs package in Debian:

Pre-Depends: e2fslibs (= 1.42.5-1), libblkid1 (>= 2.17.2), libc6 (>= 2.11), libcomerr2 (>= 1.42~WIP-2011-10-05-1), libss2 (>= 1.34-1), libuuid1 (>= 2.16), util-linux (>= 2.15~rc1-1)

It does this by maintaining a list of symbols and the version when it
was first introduced.  See the libcomerr2.symbols file, for which an
example can be found here:

http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=debian/libcomerr2.symbols;h=ce3b74a19d32ea9f43d67c976753e91ca113a894;hb=HEAD

Debian has packaging tools which will examine all of the symbols used
by the executables in a package, compare it against the .symbols file
for the library, and then determine the appropriate minimum version
needed for that library, and insert it into the package.  This is how
the e2fsprogs package automatically included a versioned dependency
for libcomerr2 1.42~WIP-2011-10-05-1 (since this was the first Debian
package which provided version 1.41.99, as specified in the
libcomerr2.symbosl file).  However, based on the symbols used from the
libss2 library, e2fsprogs only needs libss2 version of 1.34-1 or
newer.

If another package uses libcomerr2, but doesn't use the new
set_com_err_gettext() function, then the versioned dependency for that
package might be for an older version of libcomerr2.  And all of this
is done automgically by the Debian dpkg tools.  Cool!!

Unfortunately, RPM doesn't seem to do this automatically.  It looks
like you have to explicitly specify these dependencies in the spec
file.  Currently the e2fsprogs spec file for Fedora seems to mandate
that e2fslibs must match the version of e2fsprogs exactly, while any
version of libcomerr2 will do.

If we were to change the DSO version number, it would break older
executables that didn't use this new symbol, and given that the
dependency management in the RPM spec file is all horribly manual, it
wouldn't help you, since you'd have to manually adjust the dependency
in the spec file anyway.  So you might as well manually adjust it to
require at least the 1.42 version of libcom_err.

Anyway, this is a packaging bug, and Debian provides a worked example
about how this can be done completely automatically, without needing
any special handling by the release engineer.  Why RPM doesn't follow
Debian's lead by having an automated system is not something I've ever
understood (but there's a reason why I use Debian and not
Fedora.... and it's not just the abomination which is GNOME 3 / GNOME OS).

Best regards,

	       	    	     	 	     	   - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html