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

[Alexander Bokovoy]

On pe, 20 loka 2017, Rowland Penny via samba-technical wrote:
> 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 ?
> 
You are right and this is what Andreas advocates.

-- 
/ Alexander Bokovoy