[jcifs] jcifs-0.7.10 released

[Allen, Michael B (RSCH)]

This release includes minor bugfixes. See CHANGES.txt for details:

  http://users.erols.com/mballen/jcifs/

Eric,

I did not apply the NTLMv2 patches. Please recode the NTLMv2 
stuff in NtlmPasswordAuthentication.java to be consistent with the
decoding/encoding technique used throughout the smb package.

Specifically, I want the decoding/encoding technique to be consistent. All 
existing code in the smb package uses decoding/encoding methods that
pass the object being decoded/encoded, source or destination byte array,
and the index into that array where the object is being decoded or
encoded. This is much more efficient than allocting storage with 'new
byte[..]' encoding your message and then arraycopy-ing that into another 
bigger buffer also allocated dynamically, etc.  So given a byte array and
an index each object is responsible for (de)serializing itself. I call
this "Recursive Composition of Complex Formats". I don't have benchmarks
to prove what I'm saying and it may be petty to nit-pik over this but
jCIFS is not slow so whatever I'm doing can't be too bad. The specific
examples in your code are using writeUShort(ByteArrayOutputSteam,
value) which calls ByteArrayOutputSteam.write() for each byte and
NtlmPassordAuthentication.getLMv2Response() could allocate one buffer
and call write* methods to encode the "blob", data, and mac. Calling
NtlmPasswordAuthentication.getLMv2Response() creates 7 byte[] objects. I 
believe this could be reduced to 2 or maybe even 1 (in theory 0 but even
I didn't do that with the getXxxResponse methods).

The "Recursive Composition" technique also permits encoding/decoding
methods to be reused in different contexts which leads
me to a secondary problem; ServerMessageBlock.writeTime()
could have been used where you encode a 64bit TIME structure in
NtlmPaswordAuthentication.createBlob(). If the timezone is not required
the writeTime method should be modified to parameterize that.

Also, querying Properties at Runtime is very expensive. JCIFS queries
all properties in advance. Admittedly this is a flaw but I don't think
the alternative is to query them at runtime. In the future we can put all
properties in a class that exposes members of the proper type and update
that information at strategic points. Currently a static initializer
(like your MAX_REDIRECTS) should be used in favor of querying (most)
properties at runtime. It's very unlikely that someone would want to
switch between NTLM and NTLMv2 at runtime and if they did I think it
would be necessary to parameterize that in the NtlmPasswordAuthentication
constructor rather than use a global Config property.

I'm happy to see you working in the SMB layer but I have to enforce my
coding standards in there. I realize that in many cases efficiency is not
very important but if it effects something that happens very frequently
(like every SMB) could have a noticable impact on performace. I'd like
to see you use the same techniques in all the packages but if it's mosty
your code I would be a fool to complain considering you're knowledge of
HTTP and all the web service stuff that I'm clueless about.

> -----Original Message-----
> From:	eglass1 at comcast.net [SMTP:eglass1 at comcast.net]
> Sent:	Thursday, July 03, 2003 4:51 PM
> To:	jcifs at lists.samba.org
> Cc:	crh at ubiqx.mn.org
> Subject:	Various and sundry jCIFS patches
> 
> Mike/Chris/All,
> 
> Attached are various updates stemming from the NTLM research I have been doing 
> lately (it looks to be about 16K, so I'm going to take a chance that it will 
> make it out to the list...)
> 
> This includes:
> 
> * Additions and updated documentation on the NTLM flags.
> 
> * Fix to NtlmSsp to only provide the target when requested by the client via 
> the NTLM "request target" flag (this is the correct behavior).
> 
> * Bugfix to NtlmSsp to do Base64.encodeBytes(bytes, false) instead of 
> Base64.encodeBytes(bytes) (a linewrap in the header can cause an error).
> 
> * Patch to SmbComSessionSetupAndX/SmbComTreeConnectAndX to allow variable-
> length LM/NTLM responses.
> 
> and the big one,
> 
> * Support for NTLMv2 authentication.
> 
> Most of these are one-or-two-line changes, except the last one.
> 
> This adds a "jcifs.smb.lmCompatibility" property to enable NTLMv2, which mimics 
> the Windows LMCompatibilityLevel registry setting:
> 
> 0,1:    Send LM/NTLM responses (this is the default)
> 2:      Send only NTLM response
> 3,4,5:  Send LMv2/NTLMv2 responses
> 
> Actually, this really only sends LMv2; there are issues involving cross-domain 
> authentication with NTLMv2 which made it infeasible to implement properly 
> without doing significant overhauls and guesswork for minimal benefit (the code 
> for NTLMv2 is in there, but commented out since it won't work across domains 
> right now).  The servlet/filter will accept both the LMv2 and NTLMv2 responses 
> from the browser, but only send the LMv2 in the SMB session setup request.  
> Similarly, the NtlmHttpURLConnection only sends the LMv2 in the Type 3 message.
> 
> To enable LMv2 in the filter, you would just add:
> 
> <init-param>
>     <param-name>jcifs.smb.lmCompatibility</param-name>
>     <param-value>3</param-value>
> </init-param>
> 
> Likewise, enabling LMv2 for SmbFile/NtlmHttpURLConnection just involves 
> specifying:
> 
>     -Djcifs.smb.lmCompatibility=3
> 
> I have also finished the NTLM documentation at
> 
> http://davenport.sourceforge.net/ntlm.html
> 
> (or as finished as it's going to get for awhile).  I was hoping it could be 
> linked/copied to the jCIFS page as a reference.
> 
> I'm going to be in and out of vacations for about the next 5 weeks, but I'll 
> try to keep reasonably in touch.  I'm going to dig into the Davenport stuff and 
> see about getting WebDAV locks implemented; I might not be able to really focus 
> on it until things wind down a bit, though.
> 
> On a side note, have either of you guys looked into setting up a Sourceforge 
> project for jCIFS?  I've been pretty happy with using it for Davenport, so I 
> figured I'd bring it up.
> 
> 
> Eric
>  << File: patches.tgz >>