krb5 libraries and circular dependencies

[Sam Hartman]

I don't have a strong opinion on combining libk5crypto and libkrb5.  If
you combine them it's important to bump the soname of libkrb5.  That's a
dramatic change for those of us distributing krb5.  From the Debian
side, it means that testing transitions are blocked until all
dependencies of krb5 are rebuilt.  Practically it means that
dependencies of krb5 don't move into testing for around 4 months.
Obviously, that means that the integration of krb5 needs to be carefully
managed to find a time when this hit can be made.  The complications for
Ubuntu are harder to analyze.  Sometimes, Ubuntu is impacted by Debian
testing transitions--for example when preparing a long-term support
release.  Other times Ubuntu is less impacted by these sorts of issues
than Debian.

I think that if the transition costs are ignored, it clearly makes sense
to combine the libraries.  However, ABI stability and other related
transition issues are very real.  

With regard to the second issue.  I think that the reason the preauth
plugin provides the get_data_proc is to try and make some aspects of the
request have a public API when they didn't otherwise.  I don't think it
is an attempt to avoid calls into libkrb5.

I think plugins should be encouraged to call into libkrb5 when
appropriate: doing anything else seems to make writing plugins
difficult.  I'm not sure the concern of loading the wrong libkrb5 is
sufficient to need a solution, but I don't object to the mechanism of
having a function that takes the address of data.

--Sam