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
code?


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

Oleg  

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


Mime
View raw message