MIT, Heimdal and Re: [PATCH] Log transaction and authentication durations.

[Andrew Bartlett]

On Wed, 2018-06-20 at 13:52 +0200, Andreas Schneider wrote:
> On Wednesday, 20 June 2018 08:55:55 CEST Andrew Bartlett wrote:
> > 
> > OK, I've added this to the list of what isn't supported in MIT, (our
> > users do ask from time to time):
> > 
> > https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerbero
> > s_KDC#Known_Limitations_of_MIT_Kerberos_Support_in_Samba
> > 
> > The issue with the 'just ignore some features' approach is that it
> > makes getting out of Heimdal even harder, and so has us remaining in
> > this 'Keberos business'.
> 
> I don't have time to work on MIT Kerberos support for Samba AD at the moment. 
> There are things with higher priority.

Thanks for the clarification. 

> > What we do need is feature parity, comprehensive testing parity and
> > automated testing, as discussed in this thread:
> > https://lists.samba.org/archive/samba-technical/2017-November/123755.html
> 
> Well, you just add features to Samba Kerberos without any upstream Kerberos 
> discussion and you say you might deal with it some day. What are you doing if 
> Heimdal says, this change will not be accepted it is not well designed or too 
> intrusive?

I'll deal with that then.  I'm glad I didn't do that so far because we
know better now we are getting real-world use of the feature what we
actually need. 

> I can't keep up implementing new features, as I need to deal with MIT Kerberos 
> upstream, make a proposal, have a discussion to get a good API which other 
> will benefit from too.

Indeed, and this is the fundamental discussion of vendoring.  
 - Do we first assume perfect foresight, design the feature upstream,
implement it, perhaps wait for a release, implement it in Samba,
release Samba and then return to the upstream with the feedback for v2?

 - Implement it in Samba's vendor copy, release it and then work with
upstream to implement generally useful changes based on Samba's real-
world feedback and Samba's final requirements?

 - Try to muddle along in some middle road, getting as much upstream as
soon as possible, but maintain a fork long-term?

All have costs!  All have real risks!

Vendoring is evil!  Vendor everything!  

Some might say our approach (mostly the latter) has been a horrible
failure.  I would say it has been the horrible failure that has enabled
our glorious success, we wouldn't have a Samba AD DC at all without
that approach.  

(The broader Samba approach to this question has been to implement
fresh, where we get all the benefits of vendoring without the blame.)

Finally, while I could change the patch not to change the HDB API, and
instead read the time directly from the global variable or a mirror in
Samba private state (we set the time at the start of each packet), it
isn't as clear and would just change the issue from compile-time to
test-time/runtime.

I do hope we don't need to block this patch while we continue to muddle
though these difficult meta issues. 

> If we continue like that we will never get MIT Kerberos or can ever update 
> Heimdal which is from 2011! The Heimdal copy in Samba is ~1600 patches behind 
> and who knows how many ahead ...

As discussed elsewhere, I don't know how we get MIT Kerberos for the
KDC.  I don't know where to find the extra developer-years, so while I
don't deliberately want this to be harder, Samba's AD DC can't wait for
a project that is stopped either.

What we can do is ensure that we continue to build better
infrastructure, in particular stronger tests.  This will ensure that
when this is picked back up at least there are goal-posts (even if they
are moving until actually reached). 

Sorry,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba