[gnutls-dev] gnutls versioning again

[Dmitry V. Levin]

Hi,

On Thu, Feb 15, 2007 at 12:20:50PM +0100, Simon Josefsson wrote:
> Dmitry V. Levin writes:
[...]
> > Yes.  Imagine large binary package repository (e.g. Debian or Sisyphus).
> > Maintainer builds new software which uses new symbols from gnutls.
> > When user installs package with this new software, there are no indication
> > that it requires new version of gnutls, so old version of gnutls may
> > remain unupgraded.  As result, user will see runtime relocation error
> > which is not what maintainer usually want.
> 
> One solution to that is for the new software packages to have a
> versioned dependency on the newer version of the gnutls packages.

It would be error prone to rely on dependencies made by hand, especially
because there is a method to make all these necessary dependencies
automatically.

> > To resolve this issue, our gnutls package maintainer had to create new
> > interface, e.g. GNUTLS_1_6_1 and place new symbols there.  As result,
> > every package with software which uses these symbols will automatically
> > have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1),
> > so any user installing this package will also update gnutls package.
> 
> There needs to be some mechanisms here that figures out that
> application X uses symbols from libgnutls.so.13 with the GNUTLS_1_6_1
> label, and maps GNUTLS_1_6_1 back to a versioned dependency on GnuTLS
> version Y, and adds it to the application X packages.  Right?  That
> mechanism is presumably part of your package build scripts.

Not exactly.  ELF object X which uses symbols from libgnutls.so.13 with
GNUTLS_1_3 and GNUTLS_1_6_1 interface names contains not only undefined
references to these symbols but also list of required interfaces for each
soname it linked with.  When dynamic linker loads a library the ELF
object is linked with, it checks that this library provides all requested
interfaces, and aborts if check fails.

Our package build scripts just fetch these interfaces requirements from
ELF objects and place it to package metadata.  This technique seems to be
widespread.

> Why can't that mechanism check for the new APIs instead, and add the
> versioned dependency when applications use them?  That seems to amount
> to roughly the same amount of hard-coding and special mapping.  But it
> seems more reliable.

This is exactly how described mechanism works.
All it needs to work is information about API.
Symbol versioning is used to be that information.

> I wonder if it isn't easier to hand-maintain these versioned
> dependencies.  Eventually, you'll run into the situation where
> application X depends on the behaviour (i.e., not causing a security
> problem) of some API gnutls_foo in GnuTLS version P or later.  Shared
> library symbols won't protect you from this, since the shared library
> label of gnutls_foo won't be incremented when we fix a security
> problem in that function.  Only hand-maintained version information
> does.

Hand-maintained versioned dependencies cannot replace automated versioned
dependencies just because they are hand-maintained.  When automated
dependencies are not enough (like in the case described above),
hand-maintained dependencies complement (but do not replace) them.

> > Just otherwise, library should provide new symbols via new interface,
> > so an application which uses new symbols will get necessary dependencies.
> 
> As far as I understand, the linker scripts weren't designed for that
> purpose.

I can only guess what linker scripts was designed for,
but they work for that purpose long time yet.

> > If new version of a library exports new symbols, it should add new
> > interface explicitly, using version script or any other available method.
> > As I see, gnutls uses version script for this purposes.
> 
> No, GnuTLS uses version scripts to make sure that we can safely CHANGE
> the behaviour of an API function in a later release, and be sure that
> old applications will still work with the new library.  If I
> understand Drepper's paper on shared library versioning, that was what
> this feature was originally designed for.
> 
> I'll grant you that there is no really good documentation that seem to
> answer this question.  It may be that adding new APIs should cause a
> new shared library label to be added.  I see some signs that libc
> actually do this.

Yes, there is a practice to follow this way.  I remember gcc, elfutils,
libacl, libattr, libasound, libpam, but there are certainly others.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070215/4887d2e7/attachment.pgp