major architectural "split"

[Luke Kenneth Casson Leighton]

On Thu, 9 Dec 1999, Andrew Tridgell wrote:

> > that's just the way i work (commit 4 to 8 times a day) and i rely on you
> > nice people to give me feedback on things i forgot (thank you! thank you!)
> 
> but sometime, eventually, we have to do a STABLE release. 

when i get tired for a couple of months? :-)
 
> > i really, really do not want to get into the situation where here we are
> > one year later and the development branch still hasn't been merged with
> > the release branch.
> 
> the development branch turned into a release branch well over a year
> ago. Since then we have worked to try to make that release branch
> stable. It has taken us this long (and lots of rewrites) to get there.
> 
> You don't like doing the work to make code stable. Fine. But please
> don't be too critical about those of us who do try to make the damn
> stuff stable. It might not be as sexy but it does take a lot of work.
> 
> I am also pretty convinced that no matter when we decide to try to
> merge your development code in, by the time we are done you will once
> again be complaining that we shouldn't be using that old crud and
> should instead be using your all-new way of doing things whatever that
> might be.

... there are two ways to avoid that.  three :)  one, i change my
development style.  two, any development branch be no more than three
weeks old.  three, the redirector allows individual daemons to be reviewed
and replaced whenever, from whatever branch to whatever branch.

> what worries me is when we split off the rpc code and decide on a
> protocol you will then start rewriting it before we get stable to use
> xml/corba/foobar/sysv or some other weird way of talking, and you will
> just go and start stomping on all our stable smbd code to re-make it
> in whatever way you like.

i have to have a justifiable reason to do that.  i tend to work in
increments.  no successful recompile for around four days is about the
limit of the kinds of mods i make.

i am also specialising in the msrpc area, and the msrpc daemons tend to be
self-contained.  where they are not self-contained, they tend to use msrpc
calls.  if they use msrpc calls, there is already a well-defined interface
for each of those.  therefore, work on msrpc daemons is self-contained.

> I just don't trust you in the branch that we are aiming to make
> stable, you don't care enough about stability.

that's not true.

the issue is that the correct implementation and use of some of the
critical msrpc services, such as \PIPE\samr, has had an impact on areas
that would not normally be expected.

for example, the SamrSetInformationUser call, to set a user password,
requires a user session key.  the user session key is generated at the
SMBsesssetupX time, therefore a user session key must be generated in
smb_password_ok() and then stored in the connection_struct.

for example, adding support for NTLMv2 required that the nt password
length be variable instead of fixed to 24 bytes.  additionally, NTLMv2 is
dependent not just on the username but also on the domain name and server
name, therefore these parameters needed to be passed in to
smb_password_ok().

so, these changes are necessary for me to support the functionality i
chose to implement (and document).

as these changes impact security areas, they are not going to go into a
stable release until they have been reviewed.  i have no such restraints
in the development branch, therefore i just implement it and prove that it
works, and go from there.

basically, i pick an.. aim, or a goal, or a "cool thing" like unix
sockets, and run with it to see how far it will go, and what can be done
with it.  the changes required tend to ripple out from there.  "cool
things" tend to be rare.  up until unix sockets, i was being driven by
what other people wanted / asked for (e.g spoolsss job scheduling, which i
still haven't done yet.  svcctl password setting on services, which is
_way_ too complicated for right now).