Releasing Samba 4.0 RC1?

[Andrew Bartlett]

On Mon, 2012-08-13 at 11:01 +0200, Stefan (metze) Metzmacher wrote:
> Am 12.08.2012 13:59, schrieb Andrew Bartlett:
> > (TLDR: I want us to think about if we should release Samba 4.0 before or
> > after SDC and the MS plugfest). 
> > 
> > 
> > Over the past couple of months now, I have been releasing a Samba 4.0
> > beta every two weeks, as we proceed on the path to a release candidate.
> > Indeed, while I can't find the schedule right now, it called for the
> > next release (Tuesday Aug 14) to be RC1!
> > 
> > Now that I have your attention, I'm not seriously suggesting pulling an
> > RC next week, but I do want to discuss what we will do to get to making
> > an RC of Samba 4.0, and how that might fit into other major development
> > effort that is ongoing.
> > 
> > The background is that since Beta 2, s3fs has been the default and
> > hasn't caused major issues.  This was consisdered the single biggest
> > blocking issue.  That said, I am not totally happy with it, as the ACL
> > handling needs work: we set ACLs during provision that are sent to the
> > client, but not actually honoured by Samba.  I'm working to fix this. 
> > 
> > There is of course the series of bugs attached to
> > https://bugzilla.samba.org/show_bug.cgi?id=8622 but sadly most of these
> > have not seen much attention since being filed (and don't seem to be
> > bothering our production users). 
> 
> I think we should tread the once as blockers, which are
> - security/acl relevant
> - may cause directory inconsistency.
> - allow DoS attacks by doing
> 
> E.g. https://bugzilla.samba.org/show_bug.cgi?id=8620
> https://bugzilla.samba.org/show_bug.cgi?id=8621
> https://bugzilla.samba.org/show_bug.cgi?id=8638
> https://bugzilla.samba.org/show_bug.cgi?id=8929
> https://bugzilla.samba.org/show_bug.cgi?id=9089
> https://bugzilla.samba.org/show_bug.cgi?id=8077
> https://bugzilla.samba.org/show_bug.cgi?id=9029

The challenge I see with this list is that all of these issues have been
known about for quite some time (most more than a year).  How do can we
reasonably block the release when we have no reasonable prospect that
someone will step up and fix them?

> I still need to file some new bugs...

Even with this just this list, given current resources working on AD
stuff, I just don't see how we can fix these.  In the meantime, our
users seem very happy to deploy our current code, and I would prefer to
warn them about these challenges than deny them a stable release because
of them. 

Do you have any time to address these?  (From the below, it seems you
will be pretty busy on SMB3 stuff)

> > That covers the AD side of the house, but clearly there is a massive
> > development effort ongoing for the SMB3 support.  This is really
> > important, as it not only emphasises that Samba 4.0 is a major leap
> > forward across all of our many parts, but it also gives us a chance to
> > get SMB3 (even without many of the optional features) into the hands of
> > our users.  
> > 
> > My question on SMB3 is: Are we at or nearing a point in that development
> > effort where it is logical to pause and release?  
> 
> I would like to have initial support for durable handles (SMB 2.0/2.1)
> in the final release, we made good progress in last months, but there's
> still some cleanup to be done before it's ready for master.
> 
> See
> https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-durable
> 
> This branch has also support for durable handles v2 (SMB3), but we
> may need to add some more input validation there (we need to test
> against windows).
> 
> There're some other we need to check regarding input validation,
> (related to the replay and channel sequence stuff in SMB3).
> 
> I have SMB3 encryption almost ready, but as Windows clients doesn't
> behave exactly as documented, I need to have some minor details
> in this branch:
> https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-signing

How soon do you expect to land this?


> I'm ok with before or after the events, we'll need rc2, rc3 later anyway.

It would be grand if we could really treat RC1 as a real release
candidate, but I fear we will have a situation like 3.6 where we keep
bluffing our vendors and users with 'this is the real RC this time,
please test it' (while we pile more and more changes and have to release
RC after RC).  It would be good if we could focus on RC1 as the release,
and plan for 4.0.1 for fixes that are not earth-shattering.  Otherwise,
the term 'release candidate' doesn't really mean anything.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org