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

[Simo Sorce]

On Wed, Jun 20, 2018 at 06:55:55PM +1200, Andrew Bartlett via samba-technical wrote:
> On Wed, 2018-06-20 at 08:04 +0200, Andreas Schneider wrote:
> > On Wednesday, 20 June 2018 07:09:54 CEST Andrew Bartlett via samba-technical 
> > wrote:
> > > 
> > > Andreas:  Just a heads-up that this while I've confirmed this builds
> > > with MIT, you will probably need to take it into account when getting
> > > the auditing enabled for the MIT KDC.
> > 
> > Quoting you from the 'heimdal: lib/krb5: do not fail set_config_files due to 
> > parse error' thread:
> > 
> >     Once patches are in upstream git master (no need to wait for a release)
> >     they can be back-ported.  This helps for when I get back to updating
> >     our copy so we don't regress, so the effort is much appriciated.
> > 
> > The upstream hdb_auth_status callback takes 3 arguments, the one in the Samba 
> > code takes 7 arguments!
> > 
> > You're obviously already in the Kerberos business and maintain a fork of 
> > Heimdal! This seems to go in without any Heimdal upstream discussion if this 
> > feature for testing is worth changing the HDB API or if there are better ways.
> 
> Yes, in the short term we have a fork of Heimdal, and clearly I'm
> asking to do as I say, not as I do.  
> 
> What I will say is this:  Patches that either are not submitted and
> accepted upstream or don't have comprehensive unit tests inevitably be
> dropped or lost when I next do the upgrade.  Leaving cleanup and
> similar patches just in our tree is simply asking for them to get
> missed. 
> 
> While hardly a good enough reason, the reason the audit logging wasn't
> done in Heimdal first is that:
>  - upstream Heimdal has restructured that area of the code such that a
> simple forward/backport is not possible
>  - there is no public testsuite in upstream Heimdal for the hooks,
> originally added for Apple (I think). 
> 
> So, yes, I plan to deal with this element of technical debt when I get
> back to the re-sync.  While there will still be no upstream test, at
> least then we can test it by proxy of Samba's tests.  
> 
> That is, it is not a hard and fast rule, but the more we follow it the
> more practical my upgrade job is, so I just ask nicely.
> 
> > I think we will just not have auth logging support with MIT Kerberos or as an 
> > untested feature.
> 
> OK, I've added this to the list of what isn't supported in MIT, (our
> users do ask from time to time):


Can you stop moving the goal post Andrew ?


> 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'.  

The solution is to stop trying to add features downstream first, and go
upstream to have them first, then come back to Samba.
Yes it takes longer time, but it is the *right* way to do it.

> 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

No, we need to stop moving the goal post, cut our losses, move to ONE
implmentation, and work with upstream *first* for anything else that is
needed.

Once we are in good shape we get back to add features as, and if *really*
neeeded (features also are expensive to maintain and Samba is already
supercomplicated, so adding features should come with higher and higher
barries.

My 2c,
Simo.

> 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
> 
>