[Proposal] Samba 3.2.0 to replace 3.0.22

[James Peach]

On Fri, 2006-01-06 at 06:23 +1100, Andrew Bartlett wrote:
> On Thu, 2006-01-05 at 09:20 -0600, Gerald (Jerry) Carter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > * jerry steps up to the mic
> > * tap, tap, tap
> > * "Is this thing on?"
> > 
> > I've been talking to Jeremy, Guenther, Volker, and some others
> > about the upcoming changes currently in trunk.  It seems that
> > the patch pressure is getting quite high for the SAMBA_3_0 tree.
> > If you haven't followed some of the discussion, here's some of
> > the relevant threads:
> > 
> > * [PATCH] kerberize pam_winbindd (work in progress)
> > http://lists.samba.org/archive/samba-technical/2005-November/043875.html
> > 
> > * "algorithmic rid base" bogus?
> > http://lists.samba.org/archive/samba-technical/2005-December/044491.html
> > 
> > * usershare acl parser?
> > http://lists.samba.org/archive/samba-technical/2005-December/044258.html
> > 
> > * [PATCH] Autogenerated DFS parser
> > http://lists.samba.org/archive/samba-technical/2005-October/043178.html

Which of these result in incompatible changes with 3.0.*?

> Does the cluster work also fall into this?

Interesting question :)

> > So the is major work in offline winbindd support, removing legacy
> > rid algorithm support, non-root user creation of shares for desktop
> > applications like KDE & Gnome, & backporting Samba 4's IDL upport.

So you are proposing to autogenerate more IDL interfaces than just DFS?

> > None of this is designed to compete or impeed Samba 4's development.
> > In many ways it moves us closer to Samba 4's view of the future and
> > is the product of continued, active development on Samba 3.0.x.
> > However, these changes are really too sweeping to place in a 3.0.22
> > or even a 3.0.30 release for that matter.

By "sweeping", do you mean "incompatible" or just "large"? I would say
that incompatible changes could be a good rationale for bumping the
minor version, but would have to be convinced otherwise.

In general, I strongly support anything that moves the Samba3 and Samba4
codebases closer.

> Personally, I would like to see some enhanced security defaults for
> Samba 3.2.  For example, a requirement for some form of integrity
> protection on winbindd connections (either smb signing, NTLMSSP or
> schannel pipes etc), and dropping of plaintext password support by
> default.

Sounds like a good thing.

> Also, if the Samba 3.2 thing is done, I would also like to see some more
> Samba4 code pulled back.  While pulling back GENSEC probably has too
> many knobs on (have you seen how many places the credentials system has
> it's little fingers in? :-), it would be good to see ldb pulled back.  
>
> > So the proposal on the table is to move to SAMBA_3_2.  I realize
> > the implications of this wrt to documentation, distributions,
> > and developer resources.  We would be looking at a turn around time
> > of a few months.  Hopefully by Samba XP, April 24, if not sooner.
> > I propose skipping any 3.1.x releases in spite of past discussions
> > due to the expected turnaround time and start with the 3.2.0preX
> > releases as soon as the SAMBA_3_2 branch is feature complete.

Frankly, I don't know whether SGI would ship a 3.0 release and a 3.2
release on IRIX/Origin. I can't speak for SuSE, but this would certainly
complicate my life supporting Samba on SLES/Altix if SuSE chose to ship
3.0 and 3.2 versions.

> > And we will continue with any necessary bug fix or security
> > releases for 3.0.x.  Bug fix releases being the 'letter' releases
> > (3.0.21b, etc, ...) and security fixes eating a minor version
> > number as usual.

Given we already have less testing coverage than we would like,
splitting our user community into 3.0 and 3.2 is a difficult decision.
For how long would we support 3.0.*? 

> This is the big cost, but perhaps we would have that anyway.  We have
> been fortunate in that we have not had security issues since doing
> 3.0.20, but I suspect that we would all feel a bit bad leaving anybody
> on < 3.0.20 high and dry in the case of a security issue.  So perhaps it
> isn't a massive amount more work anyway.  It depends how many 'bug
> fixes' folks are tempted/demanded to spend their time on.
> 
> > * jerry opens the floor for discussion
> 
> It is really up to the Samba3 maintainers, but I certainly understand
> the reluctance to change the behaviours radically in the 3.0 series.  

I don't see any problem in changing behaviours radically within the 3.0
series, provided it is done in a compatible way. If this is not
possible, then I'll come around to the 3.2 view.

-- 
James Peach | jpeach at samba.org