I want to point out that everything I need to implement for our purposes
doesn't need to be contributed back to Apache. If you don't wish to see
the integrated Windows authentication, that can be something that I wrapper
into my own implementation. In that case, I would just contribute an
NTLMv2 implementation in pure Java that would require a username, password,
and domain to be entered.
IBM is usually pretty good about contributing back to open source. Of
course, I will need to go through the legal process, but I don't see any
reason why my request would be rejected.
Cathy Kegley
Lotus Expeditor Runtime Development
512.838.1229 (T/L: 678.1229)
[EMAIL PROTECTED]
From: Oleg Kalnichevski <[EMAIL PROTECTED]>
To: HttpComponents Project <dev@hc.apache.org>
Date: 03/03/2008 12:22 PM
Subject: Re: NTLMv2 in Apache HttpClient
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/[EMAIL
PROTECTED]
> [2]
>
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/[EMAIL
PROTECTED]
>
>
>
> >> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
