MIT Kerberos version support for the AD DC in master (eg 1.20 and 1.19)

[Alexander Bokovoy]

On pe, 25 helmi 2022, Andrew Bartlett via samba-technical wrote:
> On Fri, 2022-02-25 at 10:41 +0100, Andreas Schneider via samba-
> technical wrote:
> > On Friday, February 25, 2022 9:48:52 AM CET Andrew Bartlett via
> > samba-
> > technical wrote:
> > > I think this is a discussion worth having somewhere a little less
> > > hidden than a MR.  So sent to Samba-technical, but BCC to the
> > > MR.  Lets
> > > see if that works...
> > > 
> > > On 
> > > https://gitlab.com/samba-team/samba/-/merge_requests/2330#note_855084458
> > > Andreas, Alexander and I are caught on the philosophical point of
> > > what
> > > MIT krb5 versions we should be including runtime support for in
> > > master.
> > > 
> > > My point is that we test MIT 1.20 on Fedora.  The non-Fedora builds
> > > all
> > > build Heimdal.  That is, with these changes the MIT 1.19 support is
> > > untested in our CI, so we shouldn't put untested code in such
> > > important
> > > codepaths.
> > 
> > This is not true!
> > 
> > Take a look at the pipeline:
> > 
> > https://gitlab.com/samba-team/devel/samba/-/pipelines/478777772
> > 
> > samba-addc-mit120 - This runner tests MIT Kerberos 1.20 (pre-
> > release). It
> >                     tests the most important bits which have
> > significantly
> >                     changed. Like the KDB interface, S4U and RBCD.
> >                     If you look at the log you can see:
> >     $ if [ -x "$(command -v krb5-config)" ]; then krb5-config --
> > version; fi
> >     Kerberos 5 release 1.20-prerelease
> 
> Thanks for that.  I missed that detail when I looked over the patches,
> I didn't consider that the patch was further extending the number of
> jobs (this is a different also difficult issue). 
> 
> > 
> > samba-addc-mit-1 - This runner tests MIT Kerberos 1.19
> >     From the log:
> >     $ if [ -x "$(command -v krb5-config)" ]; then krb5-config --
> > version; fi
> >     Kerberos 5 release 1.19.2
> > 
> > samba-addc-mit-4a - This runner tests MIT Kerberos 1.19
> > samba-addc-mit-4b - This runner tests MIT Kerberos 1.19
> > samba-admem-mit - This runner tests MIT Kerberos 1.19
> > samba-mitkrb5 - This runner tests MIT Kerberos 1.19
> > 
> > > I'm honestly not making this argument to destroy the MIT KDC
> > > effort, on
> > > the contrary I want it to succeed!
> > > 
> > > But for it to be a long-term success we must also be able to learn
> > > from
> > > the past 6 months in particular to ensure we have a viable,
> > > practised
> > > process for changes need to be made in both codebases.
> > > 
> > > In particular, I'm concerned that the AD DC 'will build and
> > > securely
> > > operate against the MIT version found on enterprise distributions'
> > > is
> > > just not a promise we can keep, so setting that up as the baseline
> > > expectation sets us up to fail.
> > 
> > What sense does it make to drop support for the latest MIT Kerberos
> > release 
> > (version 1.19) and require our users to build MIT Kerberos from git
> > master 
> > with the next Samba release?
> 
> Fair enough.  This makes a lot of sense.  It also answers a bit of my
> question (that I've been trying to figure out how to artfully put) of
> how to make incremental development of features that cross the
> Samba/KDC boundary practical and viable.
> 
> More importantly this looks like a pattern we can follow - security
> releases will be harder, but even that could be handled similarly (with
> an in-script private build of MIT rather than a COPR repo).

Yes, the use of COPR is simply to provide a test target until there is a
release of MIT 1.20 available, beta or otherwise.

So the real goal is to make it an overlapping CI testing until we get
all MIT platforms to migrate to 1.20 once it is released. During past 6
months it was a real pain to work on solving conflicts when Kerberos
test suite changes were done in master without testing them against a
proper MIT target. Now that we have a capable MIT-based AD DC target,
this will hopefully be less tolling.


-- 
/ Alexander Bokovoy