Internal MIT Kerberos functions used by Samba
simo at redhat.com
Wed May 31 12:40:39 EDT 2017
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
> 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
> have a stability guarantee for this function, though.
> The real reason I followed up was to ask a question about the libkrb5
> 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
> libkrb5.so.3 since release 1.2. My hazy understanding is that
> 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 we do, it imposes some cost; if we don't, I think it basically
> 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
More information about the krbdev