Internal MIT Kerberos functions used by Samba

[Simo Sorce]

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.)
> 
> [I wrote:]
> > > The krb5_setpw_req structure is also not public.
> 
> On 03/20/2017 11:35 AM, Andreas Schneider wrote:
> > krb5_error_code decode_krb5_setpw_req(const krb5_data *code,
> >                                       krb5_data **password_out,
> >                                       krb5_principal *target_out);
> > 
> > This is the function prototype. It doesn't use any internal
> > structures. So I 
> > do not see how someone would need to use the structure you're
> > talking about.
> 
> You're right.  The flip side is that we have vague plans to
> renormalize
> decode_krb5_setpw_req() to match other encoders and use the structure
> type; see asn1_k_encode.c:1287.  That's not really important if we
> don't
> have a stability guarantee for this function, though.
> 
> 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).

> 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.

>  If we do, it imposes some cost; if we don't, I think it basically
> means
> the Samba package breaks if you upgrade libkrb5, which a downstream
> distribution might not want to tolerate.

This can be handled in other ways:
- symbol versioning
- dload() tricks
- let distributions care for it
- provide a stable wrapper you are ok exposing in the public API/ABI

Simo.