Turning off SMB1 make slashdot and theregister !

Jeremy Allison jra at samba.org
Tue Jul 30 22:34:36 UTC 2019


On Wed, Jul 31, 2019 at 10:22:15AM +1200, Andrew Bartlett wrote:
> On Tue, 2019-07-30 at 09:32 -0700, Jeremy Allison wrote:
> > 
> > I have to admit I really think this is the only workable
> > solution for the size of fileserver maintanence team we
> > have.
> > 
> > I'm working on modernizing the fileserver VFS right
> > now, and the requirements to keep SMB1 working are
> > causing massive amounts of extra work.
> > 
> > If we can ditch SMB1, many many simplifications
> > become possible in the fileserver code that require
> > enormous effort today. Take a look at the directory
> > scanning cleanup fixes I'm going to try and land
> > this week - 99% of that is fixing up old SMB1
> > code that is simply unneeded if we were SMB2+
> > only.
> > 
> > The AD-DC codebase moves forward as rapidly as
> > possible to match current Windows needs.
> > 
> > The fileserver needs to be able to do the
> > same.
> > 
> > All IMHO of course :-).
> 
> Thanks Jeremy!
> 
> It is really good to be seriously discussing this! 
> 
> We do have to be realistic as to what we can maintain.  I'm in a
> similar discussion with Andreas about how much we should rely on
> GnuTLS.  

IMHO relying on GnuTLS is a good approach, as it unifies
and simplifies our crpyto into something someone else
maintains (I hope :-).

> By discussing it broadly I hope we can draw out support or objections
> earlier than release date + 12 months (because that is just
> impractically late). 

Oh yes. I don't think we can remove SMB1 in less than one
year.

> I still think a lo-fi (will not pass all tests) SMB1 proxy is a good
> idea, but that's all, just an idea not a mandate or unwavering
> objection. 

Don't we already have this for any user that needs it ?

Linux VM running cifsfs mounting a SMB2 share, re-exporting
a SMB1 share via current (4.11) Samba.

Why do we need to add in another SMB1 implmentation
- even a proxy - into Samba to solve this ?

> Another alternative could perhaps be to support SMB1 using the current
> code, but not the full semantics. 

The complexity of the current code is what is causing
fileserver maintanence issues.

Truely, dropping SMB1 support in the fileserver
simplifies so much it will make our code much
easier to develop and maintain long term.



More information about the samba-technical mailing list