[19598] in Kerberos_V5_Development
Re: Internal MIT Kerberos functions used by Samba
daemon@ATHENA.MIT.EDU (Robbie Harwood)
Wed May 31 14:37:42 2017
From: Robbie Harwood <rharwood@redhat.com>
To: Simo Sorce <simo@redhat.com>, Greg Hudson <ghudson@mit.edu>,
Andreas Schneider <asn@samba.org>
In-Reply-To: <1496248839.929.34.camel@redhat.com>
Date: Wed, 31 May 2017 14:37:22 -0400
Message-ID: <jlg1sr4swil.fsf@thriss.redhat.com>
MIME-Version: 1.0
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: multipart/mixed; boundary="===============7804877038961518823=="
Errors-To: krbdev-bounces@mit.edu
--===============7804877038961518823==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
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.
>>=20
>> The real reason I followed up was to ask a question about the libkrb5
>> soname.
>>=20
>> 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,
=2D-Robbie
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlkvDWIACgkQJTL5F2qV
pEKfKw/7BqU4O+YEytErQZWGNub57bmM5f2oQQ08Pqxw1JNmKG8hzKF2qvf5HHm8
+MwDeuuzWhLtY9/6tgnBkEEgPf9GmOMaLAq7FZduX+wRExh1Sw9Mq8jVycvg61x5
hkd1tx8PD/Bq+eGHdZRqGzynjrNJC7GpY7NAmw8C8QwlKPT0ImlJrtH3p809y961
gb8Dc/WhzIn5hAwybYMVnOmZrGZXUqtr3awse72dMGkZP8gZ6kXHQnxdQ+4UimJx
F8l8k+K12VNYTzi6pxC2/vmVak18EN3YOGnqQra7pJ5XUgsvjKQAbmjM9yx5x5rS
iSh4HhdPF8gBtGBq+Wi+SWnMdir96fMPxVzg+Mm7zmgE9F9vsDlLlTMETiXSpVtF
Ykfq+1M2E4WEY8zgr7FDWhecZ5dZitNz9R8ULcutMeEQSO5jFW0AaJMo60j32q59
MZFTFSrfP8zlsI/WrPa0YeddEuSn6UhSV05OfqRK8rasuEA6/AA/ZuLXIAgx8gWW
rVbkOtdanYvW7/1xGu2ZKJYu2YZpZOWy4ymEGsAR6/ULBix0A005bxu4hMI2v5N1
Uzb6+eMsqnP4xDsJ0/0nslGxcwDMJuutLjLrmWWLSnMyqN08ynfSvTXZ7Bpl5qDT
Ep5z7S6+sF8SMmilumHgTDCYtCqziT/MUwl0iY2VAVEpL+Cxz+I=
=Ynzj
-----END PGP SIGNATURE-----
--=-=-=--
--===============7804877038961518823==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============7804877038961518823==--
