hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: NTLMv2 in Apache HttpClient
Date Mon, 03 Mar 2008 14:57:23 GMT
Hi Oleg,

> Not that we are able to properly maintain the existing NTLM code either.
> A better and cleaner NTLM implementation would be still be a big step
> forward.

And I don't object to a better implementation that is cross-platform
and pure Java. If it comes with decent test coverage, I'll give it a +1.
But Cathy is asking for integrated Windows authentication, too.

> We have been waiting several years for an approval to depend on LGPL
> libraries.

Have we? When and where was it requested, and by whom?
We have been waiting, yes. But for what? That the Board suddenly
announces that it is now OK to ship code with LGPL dependencies?
It's not going to happen. LGPL dependencies are a case-by-case
decision, to be made by the responsible PMC in cooperation with
the VP of the legal committee (or whatever is the correct title).
That's Sam Ruby for now.

Commons VFS has shipped with a jCIFS dependency, though they are
probably using it via smb:// URLs rather than through the API.
Recently, Trustin Lee of the MINA PMC has inquired about the
possibility to ship code that depends on LGPL by direct imports.
After an initial response of "no way",[1] there was a bit of a
discussion and that ended with a statement [2] which I interpret
as "it's ok, if...". The requirements from Apache policies are:

a) the product must be useable without the LGPL dependency
b) the LGPL dependency must not be downloaded automatically

a is a no-brainer, and b can be achieved by not having a pom.xml
in SVN and the source distribution. Call it lpgl-pom.xml and ask
folks to rename or set a link, then nobody can claim they were
not aware of the dependency.
We have our own PMC now and are no longer subject to the Jakarta
policy on LPGL dependencies. If we _want_ to, I'm sure we can
work out a strategy for releasing LGPL-dependent code with the
legal committee in less than a month, just as Trustin did. But
I'm not going to start this kind of discussion until we have a
case to discuss. Nobody has time to work on a jCIFS bridge, so
I'll just let it rest and dangle along.

 > How long do you suggest we should wait?

Sam Ruby mentioned in [2] that he doesn't know whether he can
make it for the February board meeting. I guess he didn't, and
maybe he'll miss the March one as well. But he took over his
role only late last year and was overwhelmed by new work.
The board meeting minutes were late for months, but he finally
caught up with that. Recently, a legal Wiki was created - the
first major improvement on legal-discuss I have seen for a long
time. He'll get around to it, don't worry. Turning the (in)famous
"3rd party draft" into a policy is the #1 priority of the legal


>> If the idea is to create a self-sustaining subproject for NTLM, I'm
>> all for it. But that means Incubator, not a code donation to us.
> The purpose of incubation is to form a community around a code base. The
> scope of NTLM is too narrow to expect a self-sustaining community to
> form around it. So what is the point of incubating that piece code in
> the first place? 

If it doesn't have a community that can support it, then we shouldn't
release it. Our Charter says "Java components". I intend to veto any
attempt to bring native code into this project without a reasonable
expectation of long-term support. If it's platform specific non-native
code, for example something that plugs into the SUN JDK Windows-only
classes to implement integrated Windows authentication, I might let it
pass into the unsupported contrib tree, but not into a release.
And releases are most likely what Cathy needs.

>> A question that remains is whether it makes sense to duplicate
>> the efforts of the Samba team at Apache.
> The scope of jCIFS is _significantly_ broader than just NTLM stuff.
> NTLMv1 code in HttpClient 3.1 is just a _single_ class. Even if split
> that code into a number of smaller classes it would still be nowhere
> close to jCIFS.

Then add a JNI wrapper with Windows-specific code to provide
integrated authentication. Since we'd hate to be Windows only,
we would hope that somebody does the same for Macs, if that is
possible at all. IIRC Samba supports integrated authentication
for Linux via a PAM module that hashes the password so it can
later be used for the NTLM authentication. If that works for Linux,
maybe it can be made to work on BSD, Solaris/Sparc, Solaris/x86,
AIX, HP-UX,...? Still fundamentally less than jCIFS, but surely
more than we could hope to ever handle ourselves.

No native code without developers that have the skill, interest,
and development environment to build and maintain that code.
No integrated Windows authentication without native code.
If it's a pure Java NTLM implementation with a suitable
plugin point where _sombody_else_ can fit in the native code,
fine with me.
But my first choice would still be that Cathy's people help the
jCIFS team to implement NTLMv2 there in a way that we can easily
plug it into HttpClient, while we work out the policy that
allows us to release a bridge component.


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message