Internal MIT Kerberos functions used by Samba

Greg Hudson ghudson at mit.edu
Wed May 31 11:53:39 EDT 2017


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

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


More information about the krbdev mailing list