Internal MIT Kerberos functions used by Samba

[Robbie Harwood]

Simo Sorce <simo at redhat.com> writes:

> On Wed, 2017-05-31 at 11:53 -0400, Greg Hudson wrote:
>>
>> 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.

These require nontrivial work from downstream.  The clearest example is
freeipa, which needs to lock to a specific libkdb5 version, and has to
rebuild every time the krb5 version changes.

There's also been trouble in the past with applications doing similar
things to libkadm5*, but we generally consider that their bug for using
them at all, not a krb5 problem, since there's no stability guarantee as
you say.

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

Simo is correct here; the cost is very high.

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

I was thinking a very caveat emptor approach, and just let the
application figure out what to do.  Changing the symbol name minimally
(e.g., just put a change number at the end) would work for this.

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

I think the intent is for the burden to fall on Samba here, not on krb5,
to ensure that things are working as expected.  Samba uses these
functions for test suite purposes, not at runtime, so we're not actually
looking at breaking anything on upgrade.

Andreas, what do you think?

Thanks,
--Robbie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20170531/f26f8e91/attachment.bin