[19597] in Kerberos_V5_Development
Re: Internal MIT Kerberos functions used by Samba
daemon@ATHENA.MIT.EDU (Simo Sorce)
Wed May 31 12:40:56 2017
Message-ID: <1496248839.929.34.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Greg Hudson <ghudson@mit.edu>, Andreas Schneider <asn@samba.org>
Date: Wed, 31 May 2017 12:40:39 -0400
In-Reply-To: <f0a40e2c-b7ae-0fb3-bad6-f11c62673c15@mit.edu>
Mime-Version: 1.0
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
