working long-term with the MIT KRB5 codebase in the AD DC
asn at cryptomilk.org
Fri Oct 20 07:16:25 UTC 2017
On Friday, 20 October 2017 00:45:22 CEST Andrew Bartlett via samba-technical
> On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
> > Well, install a newer libkrb5 on autobuild and we can do that.
> I don't think this is the right approach. This needs a longer
> discussion than I can do right now, but to get started:
> The reasons are:
> - sn-devel is not the only build box for Samba.
> - We have travis-ci boxes on github and Catalyst's developers use the
> scripts our samba-cloud-autobuild repo to build Samba on VMs.
> - It means we could only ever use a feature of MIT krb5 once it is
> upstream, released, packaged and installed
You see it from a developer standpoint as you always do. Distributions
especially enterprise distributions have a Kerberos version. This is the
Kerberos version they use through the distribution.
They will not accept that you build Samba with an internel MIT Kerberos
version, you have to use the one from the system!
Why? For security reasons! This way MIT Kerberos gets updated and all
applications, server processes e.g. get the security fix. You do not have to
update 200 packages because each of them has a copy of MIT Kerberos.
> Instead, we need to make MIT Kerberos a first-class part of our build
It is OK to build a version of MIT Kerberos on those machines for devloperment
but not for users! We are Linux with package managers and this security models
works since a long time because projects to not bundle each library they use!
> What I propose is:
> - Our build system uses a git reference (via a submodule or otherwise)
> to check out and build MIT krb5
That's fine just for development!
> - In Samba master, this tracks either:
> - MIT master
> - a Samba vendor fork of MIT in limited circumstances
That's extremly bad! An enterprise distribution will not allow a vendor fork
of MIT Kerberos. You use what is in the system or not.
Because of Heimdal included in Samba, Enterprise distributions do not offer
If you do the same with MIT Kerberos, all my work was "für die Tonne".
> - In Samba release branches this tracks:
> - the release branch, the released version of MIT krb5 that we will
> - This occur in parallel to the Heimdal build
I do not want a copy of yet another Kerberos library in the Samba tree. MIT
Kerberos is maintained by MIT people. Those should decide on features and take
care of it!
It is not a big deal to get features into MIT Kerberos and a developer could
install a development version of MIT Kerberos on their system if needed.
However we should not fork MIT Kerberos libraries.
> Naturally, coordination will be needed to get patches from master into
> MIT releases in time for Samba releases.
No, patches should be created and proposed upstream like with every other Open
Source project out there. We should not fork, it will diverege like we have it
with Heimdal and then you spend a lot of time bringing it up to date.
> This will resolve the issues we have seen so far, being:
> - patches breaking the MIT build
We just need the required MIT Kerberos library installed on the system.
> - MIT Releases being made that break Samba
That's something which is possible with every other library we use too. Do you
want to integrate all of them?
> - features (like auth logging) being blocked on MIT releases
This is something which happens with other libraries too. It is easy to check
if we can turn on auth logging. An this is happening with other projects too.
So next we fork GnuTLS because it blocks feature X in Samba? And then we fork
> I also propose we move Heimdal to the same system, once we get the
> current upgrade working, so we can finally kick Heimdal out of our
Heimdal should be removed from the Samba source tree.
Andreas Schneider GPG-ID: CC014E3D
www.cryptomilk.org asn at cryptomilk.org
More information about the samba-technical