[jcifs] jcifs-0.9.0 released / Documentation

[Eric]

>>True -- I was just figuring since signing would fail without preauth
>>anyways, might as well try it.
> 
> 
> Not necessarily. I have observed that session setups are not validated so
> multiple auths on the same transport work ok. The treedisconnect and
> logoffandx commands generate signing errors but that not a bug deal. With
> preauth you dont get any signature errors and it is equivalent to a
> workstation account so I advocate that as the proper solution. But I have
> seen it work without.
> 

I was looking at it from the standpoint from something like 
Davenport/NetworkExplorer (where it needs to do file operations over the 
signed connection, rather than just authentication).  This is actually a 
pretty good approach to "getting around" signing altogether.  By setting 
up signing with known credentials, we can then use the channel for 
subsequent sessions where the password is not known (i.e. "externally 
hashed").

And I think you may be correct as far as the session setups are 
concerned (although I haven't tested XP).

> 
>>Actually, if GUEST is enabled (which I know it often isn't),
>>would this set up signing as well?  I can never remember if GUEST auth
>>"counts" for signing, or if it's like the anonymous user (where no signing
>>is done).
> 
> 
> I know, I was drawing a blank on this as well. NULL credentials do NOT
> trigger signing and that is checked in our "crazy conditional" (now in new
> isSignatureSetupRequired method). But the check for GUEST is commented
> out. IIRC you claimed GUEST did not trigger signing but I later observed
> that that was not the case so I commented out the exclusion. I'll just
> have to enable guest on a machine and test it sometime.
> 

Yes, that seems correct; I'll have to dig back in the list archives, but 
I remember I had initially excluded both GUEST and anonymous from 
signing and it was incorrect.


Eric