[19599] in Kerberos_V5_Development
Re: Internal MIT Kerberos functions used by Samba
daemon@ATHENA.MIT.EDU (Andreas Schneider)
Wed May 31 17:16:43 2017
From: Andreas Schneider <asn@samba.org>
To: Robbie Harwood <rharwood@redhat.com>
Date: Wed, 31 May 2017 23:16:25 +0200
Message-ID: <26727808.cU31mzmtUl@krikkit.cryptomilk.site>
In-Reply-To: <jlg1sr4swil.fsf@thriss.redhat.com>
MIME-Version: 1.0
Cc: MIT Kerberos Dev List <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Wednesday, 31 May 2017 20:37:22 CEST Robbie Harwood wrote:
> Simo Sorce <simo@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.
We will have more incompatilbe changes with KDB in future. I will try to get
as many changes done in the next version but I'm the Samba one man show at RH
so I can not fully focus on that.
> 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?
Well mostly they are used for testing, the only thing is the kpasswd function
but I'm fine to add a configure check if that changes. I do not have a problem
here, just a header file with a prototyte is easier to check then defing it on
our own. I do not need API guarantees for these funcitons.
Andreas
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
