User: Password:
Subscribe / Log in / New account

Cascading security updates

Cascading security updates

Posted Feb 28, 2008 10:56 UTC (Thu) by nix (subscriber, #2304)
In reply to: Cascading security updates by magnus
Parent article: Cascading security updates

Symbol versioning doesn't help there unless your applications explicitly state which versions
of symbols they use (which none do because it's so annoying).

Instead they implicitly rely on a GNU extension whereby a symbol with a @@ between name and
version (rather than a single @) becomes the default version and is used if none is specified.
This is invariably the latest symbol version available for that library. So you don't gain
backcompat: what you gain is forward-compat (until you relink, anyway).

(Log in to post comments)

Cascading security updates

Posted Feb 29, 2008 20:14 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Symbol versioning actually makes the backward compatibility problem worse. Take an old program foo.c and compile it on your new system. Transport the program to an old system, and it won't run. That's because it calls baz(), which at compile/link time turned into a reference to the new Version 2 of baz().

Without symbol versioning, baz() designers would instead introduce a new baz2(), and maintain compatible header files for baz(), and the old foo.c would be unaffected.

Furthermore, a coder of a new foo.c might see in the manual that baz2() is a recent invention, and thus write foo.c to use the more ubiquitous baz(). It's hard to expect a coder to use explicit symbol versions the same way.

Last, but not least, the error message you get when you try to run that newly compiled foo.c on the old system is very cryptic, even to a seasoned software engineer.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds