Internal MIT Kerberos functions used by Samba

[Benjamin Kaduk]

On Wed, May 31, 2017 at 12:40:39PM -0400, Simo Sorce wrote:
> On Wed, 2017-05-31 at 11:53 -0400, Greg Hudson wrote:
> > (Continuing a conversation from March 20.  Please read if you are
> > responsible for packaging MIT krb5 for an OS distribution.)
> > [...]
> > The real reason I followed up was to ask a question about the libkrb5
> > soname.
> > 
> > For libkadm5clnt, libkadm5srv, and libkdb5, we install a header file
> > with a comment noting that the API isn't stable, but we do change the
> > library soname (via LIBMAJOR in Makefile.in) each time we make
> > incompatible changes to the ABI.
> > 
> > For libkrb5, we haven't changed the soname in a long time; it has sat
> > at
> > libkrb5.so.3 since release 1.2.  My hazy understanding is that
> > changing
> > the soname would impose a moderate maintenance cost on downstream
> > distributions, but I don't know the magnitude of that cost.
> 
> For a foundational library like libkrb5 which is linked in a lot of
> software I would define the cost high, it basically requires a rebuild
> of all dependent code, and it mans incompatibility with existing
> binaries, which may or not be rebuildable (source code not always
> available or FTBFS issues may arise).

Agreed on the high impact; it would be a pretty extensive library
transition for Debian.  (Which, to be clear, there are procedures
for and it is doable in the needed timescale between releases, but
does require effort and coordination.)


> > So if we do install a header file prototyping some semi-public
> > libkrb5 functions, and later change them, do we plan to bump the
> > library soname?
> 
> Well, in theory if you change exposed symbols you should, independently
> of whether there are header files or not.
> That said, if this is a private API, marked as so, I do not see why you
> would bump the soname. I would though, change the symbol name, and
> either maintain a compatibility symbol or have the header use some
> dload() trick to check if the symbol is available and gracefully fail
> if not.

Having symbols not visible in a public header is useful for us to
convince ftpmaster/release-team of the correctness of our packaging
changes (e.g., when symbols are removed from libkrb5support); I
don't know that we 100% rely on that, but would be cautious about
removing that property.

-Ben