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

[Andreas Schneider]

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


-- 
Andreas Schneider                   GPG-ID: CC014E3D
www.cryptomilk.org                asn at cryptomilk.org