hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NTLMv2 in Apache HttpClient
Date Mon, 03 Mar 2008 18:21:24 GMT

On Mon, 2008-03-03 at 15:57 +0100, Roland Weber wrote: 
> 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?

Yes, we have.

> When and where was it requested, and by whom?
> We have been waiting, yes. But for what?

A _consistent_, _ASF wide policy_ on the use of LGPL licensed code 

> 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, 

They no longer do. jCIFS module had to be moved to sandbox largely
because of the LGPL issue.

> 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
> committee.
> [1] 
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3c3d4032300801220524v58d8b261r23d3c40feae3db33@mail.gmail.com%3e
> [2] 
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3c4799B7D0.6090809@intertwingly.net%3e
> >> 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.

Roland, you cannot expect a community to form around such a small code
base with such a narrow scope. Is there a community around HttpConn

>  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.

We do not even know what code IBM is prepared to donate at this point,
if any at all. Your threats of vetoing contributions achieve nothing but
driving potential contributors away.


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

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

View raw message