The road to add support for MIT Kerberos to be able to release Samba 4.0

[Andrew Bartlett]

On Mon, 2012-05-07 at 08:57 -0400, simo wrote:
> Hi all,
> I and Alexander have been working on a document that explains how/why we
> are working on getting MIT Kerberos support for Samba 4 builds for at
> least all the non-DC parts of Samba.
> The (K)DC part cannot be implemented as easily so we decided to not
> consider it a blocker for a 4.0 release although very highly desirable
> for a 4.1 build.
> 
> Please see about it here:
> https://wiki.samba.org/index.php/MIT_Build

Simo,

Thank you very much for writing this down.  I wish you the very best
with the patches you are preparing, and appreciate you letting me review
them - I have found that very helpful.

There seems to be 3 key issues that you raise on that page:
 - Making Samba's top level build compile with MIT Kerberos (for client
libraries at least)
 - Allowing distributors to ship portions of Samba (potentially in
different packages), and reducing the 'unnecessary' dependencies of some
of those portions
 - Building without any Heimdal-derived code what-soever. 

I see these as being in decreasing order of importance - that is,
clearly it is critical for you (but not, in my view a blocker for a 4.0
release if you cannot achieve it) to separate your distribution of Samba
from Heimdal.  I've seen you write often about your concerns here, the
most concrete being incompatible ccache formats for S4U2Proxy. 

That said, you state:
> It is impossible to confidently segregate two libraries with
> conflicting symbols unless static linking or full symbol renaming
> techniques are employed. Neither is done in current Samba code.

Could you perhaps include a reference to a real-world failure of the
symbol versioning?  It would help us either deal with it, or at least
document it for future understanding.

As to the issues with dependencies in the waf build, this seems to be
mostly an issue if you wish to ship only parts of Samba.  While some
dependencies are easily resolved (such as the way the exportkeytab code
was moved out of libnet, avoiding a dependency on the KDC which you
can't ship), I don't yet fully understand the urgency on the remaining
parts, except that it isn't how you wish to package Samba.  Either way,
I think it needs to be separated and detailed distinctly to the MIT krb5
issue.  

On HAVE_KRB5, perhaps it isn't clear, but the only purpose of HAVE_KRB5
in header files is to allow the autoconf build to continue to function
without kerberos headers on the system.  

On the role of private libraries - private libraries are most often
created so as to ensure that code is not linked into two subsystems that
will then be linked into the same binary or library (causing duplicate
symbols).  I do agree that this does create a lot of private libraries,
but I do not see a good alternate solution at this point. 

In terms of the dependency chain, perhaps this would be a good meaning
for deps and public_deps?  That is, declare in public_deps the things
that header files published for this subsystem need, and only propogate
it for -I, rather than link-time?

On the final point, that is that we use the roken DNS library:  I can
understand why it might be valuable to change, so that we can use the
internal DNS server in make test, but why is this a MIT kerberos issue?
Are you under a restriction that prohibits the use of any
Heimdal-derived code, even when it isn't in the krb5 namespace?  (The
reason I ask is that I would like the option to be able to move to
generated ASN.1 code, and I would prefer not to make a rule that would
prohibit the use of that compiler). 

I hope this helps you understand my concerns,

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org