SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[Luke Kenneth Casson Leighton]

On Wed, 9 Feb 100 jeremy at varesearch.com wrote:

> > jeremy, i think tht you may be considering that the server-implementation
> > code in 2_0 is "considerably more reliable" because of about... four
> > changes in functionality.  the tng code DWARFS the 2_0 code in comparison
> > -- 7,655 lines of code compared to 21,511.
> > 
> 
> No Luke, you don't get it. I'm not talking about the functions
> you are referring to *at all*. I know the code that implements
> these in TNG is better and should be used (once reviewed).

[see rest of message, i got it the wrong way round]
 
> I am talking about the whole underlying substrate of the
> rpc_parse stuff, and the way the 2.0.x code handles the
> PDUs and buffers for the RPC packets. It is *this* code
> that is more advanced in 2.0.x, not the server functions.

based on your work there, and some really irritating memory corruption
errors i kept getting, i too replaced and rewrote the rpc_parse code in
tng.

you trust that code and think it's more advanced, because you wrote it,
and understand it.
 
> I know this code is missing the fault PDU, and the NTLMv2
> stuff, but this is easily added on top of the stable code
> that handles RPC packets in 2.0.x.

no it can't.  check the review i did.  there's entire areas of
fucntionality missing from rpc packet-handling code.

1) SSPI abstraction.

2) netlogon secure channel as an SSPI instance

3) SMBwrite and SMBtrans and SMBtranss multi-PDU support, needed for
jean-francois' work on spoolss.

if you want to back-port this fucntionality to 2.0, go ahead.  if that's
the only way it will get into a release, fine.  [actually, not fine, but
it doesn't look like there's anything i can _do_ about it].

> J.F. agrees with me on this.
> 
> I thought I explicitly mentioned that :-). Aparently not
> clearly enough :-). That's what I meant when I spoke about
> the "server implementation" in TNG being more advanced, but
> the RPC code in the 2.0.x branch being better.

ah, i thought you meant server-instance implementations, so i got it the
wrong way round.

i included this code in a review.  it too is also not up to scratch.
sorry.