working long-term with the MIT KRB5 codebase in the AD DC

[Rowland Penny]

On Fri, 20 Oct 2017 09:16:25 +0200
Andreas Schneider via samba-technical <samba-technical at lists.samba.org>
wrote:

> On Friday, 20 October 2017 00:45:22 CEST Andrew Bartlett via
> samba-technical wrote:
> > 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 system.
> 
> 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 Samba AD.
> 
> 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 support
> >  - 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.
> 
> NO FORK!
> 
> > 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 glibc ...
> 
> > 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
> > tree.
> 
> Heimdal should be removed from the Samba source tree.
> 
> 
> 	Andreas
> 
> 

I thought the whole idea behind getting Samba to work with the system
MIT kerberos, was to get:
A) a more up to date kerberos
B) Samba out of the kerberos business

Am I wrong ?

Rowland