You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2008/02/28 11:40:02 UTC
Re: NTLMv2 in Apache HttpClient
On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wrote:
> Hi Oleg,
>
Hi Cathy
> I am investigating what it would take to add NTLMv2 support to the Apache HttpClient as well as integrated Windows authentication for both NTLMv1 and v2. I have seen your name on numerous messages in the forum regarding NTLM, so thought I write you. Is this support something you would be interested to see contributed back to the HttpClient? What are the restrictions on this?
>
Absolutely. We would love to see a better support for NTLMv2 in
HttpClient. However, we cannot accept any code unless we are absolutely
sure (1) it can be licensed or re-licensed under ASLv2 and (2) it does
not infringe on any Microsoft patents. The latter condition pretty much
implies some company with close ties to Microsoft and lots of legal
muscles going into the trouble of taking this issue up directly with
Microsoft.
Exactly for the above stated reasons we would like to use an external
library for the NTLM support to be free of having to deal with all these
legal troubles.
> I saw on the NTLM FAQ page that the use of jCIFS is currently under investigation for licensing issues. Has anything more come of that?
>
No, it has not. No one volunteered so far to do all the leg work.
> Are there any plans to add support for NTLMv2 or the integrated Windows authentication in the near future?
>
Currently not a single active committer on the project expressed any
interest in working on it in the foreseeable future. So, essentially we
are waiting for some external contributor to turn up with a solution
"scratching his/her own itch", so to speak.
Oleg
PS: I am sending a copy of this message to the HttpComponents dev list
to keep the rest of the team in the loop. It would be really great if
you subscribed to the list, should you be interested in discussing the
subject further.
http://hc.apache.org/mail-lists.html
> Thanks.
> Cathy Kegley
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2008-03-01 at 17:48 +0100, Erik Abele wrote:
> On 28.02.2008, at 21:00, Oleg Kalnichevski wrote:
>
> > ...
> >> Can you contact the necessary people on the Apache side to ensure
> >> that
> >> any implementation I provide, based solely on these specs, could be
> >> contributed to the HttpClient?
> >>
> >
> > Sure.
> >
> > Roland, Erik, I gather you both are subscribed to the legal@apache
> > list
> > already?
>
> Yep, I'm subscribed to legal-discuss@ and -internal@.
>
> > Would it be a big deal for you post a question to our legal
> > team whether the two specs mentioned previously would be enough to
> > accept a clean room implementation of the NTLM authentication scheme
> > based on those specs?
>
> Done, fits nicely with the recent discussion re MS Open Spec Promise
> [1] - will get back to this list as soon as there's something concrete.
>
You are the greatest! Many thanks, Erik!
It seems we have a potential contributor willing to contribute a major
piece of code. We ought not lose this opportunity.
Oleg
> Cheers,
> Erik
>
> [1] http://www.microsoft.com/interop/osp/default.mspx
>
>
> ---------------------------------------------------------------------
> 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
Re: NTLMv2 in Apache HttpClient
Posted by Erik Abele <er...@codefaktor.de>.
On 28.02.2008, at 21:00, Oleg Kalnichevski wrote:
> ...
>> Can you contact the necessary people on the Apache side to ensure
>> that
>> any implementation I provide, based solely on these specs, could be
>> contributed to the HttpClient?
>>
>
> Sure.
>
> Roland, Erik, I gather you both are subscribed to the legal@apache
> list
> already?
Yep, I'm subscribed to legal-discuss@ and -internal@.
> Would it be a big deal for you post a question to our legal
> team whether the two specs mentioned previously would be enough to
> accept a clean room implementation of the NTLM authentication scheme
> based on those specs?
Done, fits nicely with the recent discussion re MS Open Spec Promise
[1] - will get back to this list as soon as there's something concrete.
Cheers,
Erik
[1] http://www.microsoft.com/interop/osp/default.mspx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2008-02-28 at 13:37 -0600, Cathy L Kegley wrote:
> I would be willing to take on the implementation. It is function we
> need to support for some of our customers and I am currently
> investigating the best way to provide it. I think that if it can be
> included in the Apache HttpClient, that would be the best way.
>
Great!!!
> Can you contact the necessary people on the Apache side to ensure that
> any implementation I provide, based solely on these specs, could be
> contributed to the HttpClient?
>
Sure.
Roland, Erik, I gather you both are subscribed to the legal@apache list
already? Would it be a big deal for you post a question to our legal
team whether the two specs mentioned previously would be enough to
accept a clean room implementation of the NTLM authentication scheme
based on those specs?
Oleg
> Thanks.
>
> Cathy Kegley
>
>
> Lotus Expeditor Runtime Development
> 512.838.1229 (T/L: 678.1229)
> ckegley@us.ibm.com
>
> Inactive hide details for Oleg Kalnichevski ---02/28/2008 01:32:01
> PM---On Thu, 2008-02-28 at 09:03 -0600, Cathy L Kegley wroteOleg
> Kalnichevski ---02/28/2008 01:32:01 PM---On Thu, 2008-02-28 at 09:03
> -0600, Cathy L Kegley wrote:
>
>
> From:
>
> Oleg Kalnichevski
> <ol...@apache.org>
>
> To:
>
> HttpComponents Project
> <de...@hc.apache.org>
>
> Cc:
>
> Cathy L Kegley/Austin/IBM@IBMUS
>
> Date:
>
> 02/28/2008 01:32 PM
>
> Subject:
>
> Re: NTLMv2 in Apache HttpClient
>
>
> ______________________________________________________________________
>
>
>
>
> On Thu, 2008-02-28 at 09:03 -0600, Cathy L Kegley wrote:
> > Hi Oleg,
> >
> > Microsoft recently released a bunch of open protocol specification
> on
> > MSDN. NTLM is included in that. These are the specs I have been
> > looking at:
> >
> >
> http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NLMP%5D.pdf
> >
> http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NTHT%5D.pdf
> >
> > Does this ease any of the legal implications for Apache?
> >
>
> Yes, this does sound very encouraging, but someone from the legal team
> would still have to look at the documents and give us a formal okay.
> And
> we would still need to find a volunteer prepared to take on a "clean
> room" implementation of the spec.
>
> Oleg
>
>
> >
> > Cathy Kegley
> >
> >
> > Lotus Expeditor Runtime Development
> > 512.838.1229 (T/L: 678.1229)
> > ckegley@us.ibm.com
> >
> > Inactive hide details for Oleg Kalnichevski ---02/28/2008 04:40:55
> > AM---On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wOleg
> > Kalnichevski ---02/28/2008 04:40:55 AM---On Wed, 2008-02-27 at 15:18
> > -0800, ckegley@us.ibm.com wrote:
> >
> >
> > From:
> >
> > Oleg Kalnichevski
> > <ol...@apache.org>
> >
> > To:
> >
> > Cathy L Kegley/Austin/IBM@IBMUS
> >
> > Cc:
> >
> > HttpComponents Project
> > <de...@hc.apache.org>
> >
> > Date:
> >
> > 02/28/2008 04:40 AM
> >
> > Subject:
> >
> > Re: NTLMv2 in Apache HttpClient
> >
> >
> >
> ______________________________________________________________________
> >
> >
> >
> >
> > On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wrote:
> > > Hi Oleg,
> > >
> >
> > Hi Cathy
> >
> > > I am investigating what it would take to add NTLMv2 support to the
> > Apache HttpClient as well as integrated Windows authentication for
> > both NTLMv1 and v2. I have seen your name on numerous messages in
> the
> > forum regarding NTLM, so thought I write you. Is this support
> > something you would be interested to see contributed back to the
> > HttpClient? What are the restrictions on this?
> > >
> >
> > Absolutely. We would love to see a better support for NTLMv2 in
> > HttpClient. However, we cannot accept any code unless we are
> > absolutely
> > sure (1) it can be licensed or re-licensed under ASLv2 and (2) it
> does
> > not infringe on any Microsoft patents. The latter condition pretty
> > much
> > implies some company with close ties to Microsoft and lots of legal
> > muscles going into the trouble of taking this issue up directly with
> > Microsoft.
> >
> > Exactly for the above stated reasons we would like to use an
> external
> > library for the NTLM support to be free of having to deal with all
> > these
> > legal troubles.
> >
> > > I saw on the NTLM FAQ page that the use of jCIFS is currently
> under
> > investigation for licensing issues. Has anything more come of that?
> > >
> >
> > No, it has not. No one volunteered so far to do all the leg work.
>
> >
> > > Are there any plans to add support for NTLMv2 or the integrated
> > Windows authentication in the near future?
> > >
> >
> > Currently not a single active committer on the project expressed any
> > interest in working on it in the foreseeable future. So, essentially
> > we
> > are waiting for some external contributor to turn up with a solution
> > "scratching his/her own itch", so to speak.
> >
> > Oleg
> >
> > PS: I am sending a copy of this message to the HttpComponents dev
> list
> > to keep the rest of the team in the loop. It would be really great
> if
> > you subscribed to the list, should you be interested in discussing
> the
> > subject further.
> >
> > http://hc.apache.org/mail-lists.html
> >
> > > Thanks.
> > > Cathy Kegley
> > >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: NTLMv2 in Apache HttpClient
Posted by Cathy L Kegley <ck...@us.ibm.com>.
I would be willing to take on the implementation. It is function we need
to support for some of our customers and I am currently investigating the
best way to provide it. I think that if it can be included in the Apache
HttpClient, that would be the best way.
Can you contact the necessary people on the Apache side to ensure that any
implementation I provide, based solely on these specs, could be contributed
to the HttpClient?
Thanks.
Cathy Kegley
Lotus Expeditor Runtime Development
512.838.1229 (T/L: 678.1229)
ckegley@us.ibm.com
From: Oleg Kalnichevski <ol...@apache.org>
To: HttpComponents Project <de...@hc.apache.org>
Cc: Cathy L Kegley/Austin/IBM@IBMUS
Date: 02/28/2008 01:32 PM
Subject: Re: NTLMv2 in Apache HttpClient
On Thu, 2008-02-28 at 09:03 -0600, Cathy L Kegley wrote:
> Hi Oleg,
>
> Microsoft recently released a bunch of open protocol specification on
> MSDN. NTLM is included in that. These are the specs I have been
> looking at:
>
>
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NLMP%5D.pdf
>
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NTHT%5D.pdf
>
> Does this ease any of the legal implications for Apache?
>
Yes, this does sound very encouraging, but someone from the legal team
would still have to look at the documents and give us a formal okay. And
we would still need to find a volunteer prepared to take on a "clean
room" implementation of the spec.
Oleg
>
> Cathy Kegley
>
>
> Lotus Expeditor Runtime Development
> 512.838.1229 (T/L: 678.1229)
> ckegley@us.ibm.com
>
> Inactive hide details for Oleg Kalnichevski ---02/28/2008 04:40:55
> AM---On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wOleg
> Kalnichevski ---02/28/2008 04:40:55 AM---On Wed, 2008-02-27 at 15:18
> -0800, ckegley@us.ibm.com wrote:
>
>
> From:
>
> Oleg Kalnichevski
> <ol...@apache.org>
>
> To:
>
> Cathy L Kegley/Austin/IBM@IBMUS
>
> Cc:
>
> HttpComponents Project
> <de...@hc.apache.org>
>
> Date:
>
> 02/28/2008 04:40 AM
>
> Subject:
>
> Re: NTLMv2 in Apache HttpClient
>
>
> ______________________________________________________________________
>
>
>
>
> On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wrote:
> > Hi Oleg,
> >
>
> Hi Cathy
>
> > I am investigating what it would take to add NTLMv2 support to the
> Apache HttpClient as well as integrated Windows authentication for
> both NTLMv1 and v2. I have seen your name on numerous messages in the
> forum regarding NTLM, so thought I write you. Is this support
> something you would be interested to see contributed back to the
> HttpClient? What are the restrictions on this?
> >
>
> Absolutely. We would love to see a better support for NTLMv2 in
> HttpClient. However, we cannot accept any code unless we are
> absolutely
> sure (1) it can be licensed or re-licensed under ASLv2 and (2) it does
> not infringe on any Microsoft patents. The latter condition pretty
> much
> implies some company with close ties to Microsoft and lots of legal
> muscles going into the trouble of taking this issue up directly with
> Microsoft.
>
> Exactly for the above stated reasons we would like to use an external
> library for the NTLM support to be free of having to deal with all
> these
> legal troubles.
>
> > I saw on the NTLM FAQ page that the use of jCIFS is currently under
> investigation for licensing issues. Has anything more come of that?
> >
>
> No, it has not. No one volunteered so far to do all the leg work.
>
> > Are there any plans to add support for NTLMv2 or the integrated
> Windows authentication in the near future?
> >
>
> Currently not a single active committer on the project expressed any
> interest in working on it in the foreseeable future. So, essentially
> we
> are waiting for some external contributor to turn up with a solution
> "scratching his/her own itch", so to speak.
>
> Oleg
>
> PS: I am sending a copy of this message to the HttpComponents dev list
> to keep the rest of the team in the loop. It would be really great if
> you subscribed to the list, should you be interested in discussing the
> subject further.
>
> http://hc.apache.org/mail-lists.html
>
> > Thanks.
> > Cathy Kegley
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2008-02-28 at 09:03 -0600, Cathy L Kegley wrote:
> Hi Oleg,
>
> Microsoft recently released a bunch of open protocol specification on
> MSDN. NTLM is included in that. These are the specs I have been
> looking at:
>
> http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NLMP%5D.pdf
> http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NTHT%5D.pdf
>
> Does this ease any of the legal implications for Apache?
>
Yes, this does sound very encouraging, but someone from the legal team
would still have to look at the documents and give us a formal okay. And
we would still need to find a volunteer prepared to take on a "clean
room" implementation of the spec.
Oleg
>
> Cathy Kegley
>
>
> Lotus Expeditor Runtime Development
> 512.838.1229 (T/L: 678.1229)
> ckegley@us.ibm.com
>
> Inactive hide details for Oleg Kalnichevski ---02/28/2008 04:40:55
> AM---On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wOleg
> Kalnichevski ---02/28/2008 04:40:55 AM---On Wed, 2008-02-27 at 15:18
> -0800, ckegley@us.ibm.com wrote:
>
>
> From:
>
> Oleg Kalnichevski
> <ol...@apache.org>
>
> To:
>
> Cathy L Kegley/Austin/IBM@IBMUS
>
> Cc:
>
> HttpComponents Project
> <de...@hc.apache.org>
>
> Date:
>
> 02/28/2008 04:40 AM
>
> Subject:
>
> Re: NTLMv2 in Apache HttpClient
>
>
> ______________________________________________________________________
>
>
>
>
> On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wrote:
> > Hi Oleg,
> >
>
> Hi Cathy
>
> > I am investigating what it would take to add NTLMv2 support to the
> Apache HttpClient as well as integrated Windows authentication for
> both NTLMv1 and v2. I have seen your name on numerous messages in the
> forum regarding NTLM, so thought I write you. Is this support
> something you would be interested to see contributed back to the
> HttpClient? What are the restrictions on this?
> >
>
> Absolutely. We would love to see a better support for NTLMv2 in
> HttpClient. However, we cannot accept any code unless we are
> absolutely
> sure (1) it can be licensed or re-licensed under ASLv2 and (2) it does
> not infringe on any Microsoft patents. The latter condition pretty
> much
> implies some company with close ties to Microsoft and lots of legal
> muscles going into the trouble of taking this issue up directly with
> Microsoft.
>
> Exactly for the above stated reasons we would like to use an external
> library for the NTLM support to be free of having to deal with all
> these
> legal troubles.
>
> > I saw on the NTLM FAQ page that the use of jCIFS is currently under
> investigation for licensing issues. Has anything more come of that?
> >
>
> No, it has not. No one volunteered so far to do all the leg work.
>
> > Are there any plans to add support for NTLMv2 or the integrated
> Windows authentication in the near future?
> >
>
> Currently not a single active committer on the project expressed any
> interest in working on it in the foreseeable future. So, essentially
> we
> are waiting for some external contributor to turn up with a solution
> "scratching his/her own itch", so to speak.
>
> Oleg
>
> PS: I am sending a copy of this message to the HttpComponents dev list
> to keep the rest of the team in the loop. It would be really great if
> you subscribed to the list, should you be interested in discussing the
> subject further.
>
> http://hc.apache.org/mail-lists.html
>
> > Thanks.
> > Cathy Kegley
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Cathy L Kegley <ck...@us.ibm.com>.
Hi Oleg,
Microsoft recently released a bunch of open protocol specification on MSDN.
NTLM is included in that. These are the specs I have been looking at:
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NLMP%5D.pdf
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NTHT%5D.pdf
Does this ease any of the legal implications for Apache?
Cathy Kegley
Lotus Expeditor Runtime Development
512.838.1229 (T/L: 678.1229)
ckegley@us.ibm.com
From: Oleg Kalnichevski <ol...@apache.org>
To: Cathy L Kegley/Austin/IBM@IBMUS
Cc: HttpComponents Project <de...@hc.apache.org>
Date: 02/28/2008 04:40 AM
Subject: Re: NTLMv2 in Apache HttpClient
On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wrote:
> Hi Oleg,
>
Hi Cathy
> I am investigating what it would take to add NTLMv2 support to the Apache
HttpClient as well as integrated Windows authentication for both NTLMv1 and
v2. I have seen your name on numerous messages in the forum regarding
NTLM, so thought I write you. Is this support something you would be
interested to see contributed back to the HttpClient? What are the
restrictions on this?
>
Absolutely. We would love to see a better support for NTLMv2 in
HttpClient. However, we cannot accept any code unless we are absolutely
sure (1) it can be licensed or re-licensed under ASLv2 and (2) it does
not infringe on any Microsoft patents. The latter condition pretty much
implies some company with close ties to Microsoft and lots of legal
muscles going into the trouble of taking this issue up directly with
Microsoft.
Exactly for the above stated reasons we would like to use an external
library for the NTLM support to be free of having to deal with all these
legal troubles.
> I saw on the NTLM FAQ page that the use of jCIFS is currently under
investigation for licensing issues. Has anything more come of that?
>
No, it has not. No one volunteered so far to do all the leg work.
> Are there any plans to add support for NTLMv2 or the integrated Windows
authentication in the near future?
>
Currently not a single active committer on the project expressed any
interest in working on it in the foreseeable future. So, essentially we
are waiting for some external contributor to turn up with a solution
"scratching his/her own itch", so to speak.
Oleg
PS: I am sending a copy of this message to the HttpComponents dev list
to keep the rest of the team in the loop. It would be really great if
you subscribed to the list, should you be interested in discussing the
subject further.
http://hc.apache.org/mail-lists.html
> Thanks.
> Cathy Kegley
>
Re: NTLMv2 in Apache HttpClient
Posted by Erik Abele <er...@codefaktor.de>.
On 02.03.2008, at 21:12, Oleg Kalnichevski wrote:
> On Sun, 2008-03-02 at 09:16 +0100, Roland Weber wrote:
>>> ...
>>> Absolutely. We would love to see a better support for NTLMv2 in
>>> HttpClient.
>>
>> Yes, we would love to see better support for NTLMv2 in HttpClient.
>> But what we would not want to see is somebody dropping a huge block
>> of code on us without giving further support. There will be user
>> questions on how things work or why they don't, and there will be
>> bugs that need fixing.
>
> Roland
>
> 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.
Yes, I agree with Oleg.
>> ...
>> 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?
Right, I don't think NTLM support would justify a separate self-
sustaining community/project. Though we'd need to go through
Incubator anyway, just for the short-track intended for code
donations (just IP clearance, no community building).
But first let's see which answer we get in regard to the legal side;
we can then still decide what to do and where to go etc.
Cheers,
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by sebb <se...@gmail.com>.
On 03/03/2008, Roland Weber <os...@dubioso.net> wrote:
> Hi Sebastian,
>
>
> > Or declare it as a system dependency?
> >
>
> I believe that the "system dependency" clause was meant
> for generic APIs, like JDBC or the Java URL handlers.
> If we're directly importing implementation packages of
> an external library, it won't pass as a system dependency.
>
Or maybe "provided" then?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Roland Weber <os...@dubioso.net>.
Hi Sebastian,
> Or declare it as a system dependency?
>
I believe that the "system dependency" clause was meant
for generic APIs, like JDBC or the Java URL handlers.
If we're directly importing implementation packages of
an external library, it won't pass as a system dependency.
>> We have our own PMC now and are no longer subject to the Jakarta
>> policy on LPGL dependencies.
>
> Not sure I follow that; surely the Jakarta rules are derived from ASF rules?
I didn't make myself clear here. While we were at Jakarta,
we would have had to stick to the Jakarta-defined policy,
or discuss with the Jakarta PMC to change that policy.[1]
It surely was derived from ASF rules, but had it's own set of
requirements. For example, the first item said "you have to
ask the author(s) of the LGPLd library for dual licensing".
That was surely a Jakarta thing and not a mandatory ASF policy.
Btw, the Jakarta policy has been dropped in favour of the
3rd party draft.
cheers,
Roland
[1] http://wiki.apache.org/jakarta/Using_LGPL'd_code?action=recall&rev=5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by sebb <se...@gmail.com>.
On 03/03/2008, Roland Weber <os...@dubioso.net> 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? 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.
Or declare it as a system dependency?
> We have our own PMC now and are no longer subject to the Jakarta
> policy on LPGL dependencies.
Not sure I follow that; surely the Jakarta rules are derived from ASF rules?
> 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.
+1
> > 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. 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.
+1
> 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.
+1
> 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
Re: NTLMv2 in Apache HttpClient
Posted by Cathy L Kegley <ck...@us.ibm.com>.
Hi Roland,
Help with the APIs would be greatly appreciated. I still need to review
the details of the Apache implementation of NTLMv1, but you are correct in
that I will need a plugin point where the hashes are computed. Since your
mind is tainted from the Sun implementation, who can I work with to make
sure my solution is something both IBM and Apache are happy with?
To give you an idea of my time frame, I hope to have a working
implementation by the end of May or mid-June. (Unless things go awry.)
Thanks!
Cathy Kegley
Lotus Expeditor Runtime Development
512.838.1229 (T/L: 678.1229)
ckegley@us.ibm.com
From: Roland Weber <os...@dubioso.net>
To: HttpComponents Project <de...@hc.apache.org>
Date: 03/05/2008 11:25 AM
Subject: Re: NTLMv2 in Apache HttpClient
Hi Cathy,
> 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
"don't wish to see" is a bit more than I intended to express. I don't
think that the *HC* *repository* is the right place for such code. If
it's OK for you and IBM, you could for example attach that part of the
code to a JIRA issue, and we would point interested parties there. We
could also run the code through the IP clearance, so that other projects
at Apache can use it without further ado. In particular, I assume that
Harmony[1] could make good use of such a contribution. They have
to deal with native and platform specific code anyway, so that is not
an additional burden to them. Some IBMers are also active there.
[1] http://harmony.apache.org/
> 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.
That seems to be the best strategy to go forward. What you will
probably need is a plugin point where a hash is computed from the
username/password/domain data. Windows will not give you the
password in clear text, you'll only get the precomputed hash (iirc).
So the API needs to be callable with actual credentials, in which
case the hash is computed from the data. And it needs to be callable
without credentials, in which case the hash is obtained through a
native call. We can help you with the API design, but I won't be
able to contribute code in this area since I had a look at the
SUN Java code for NTLM authentication a few years ago. That doesn't
match the clean room requirements.
> IBM is usually pretty good about contributing back to open source.
Yes, processes obviously have improved a lot since I last had to do
with them. At the time, there was nothing short of starting a new
project worth several person-years that would have justified the
effort of getting the approval to contribute anything at all :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Roland Weber <os...@dubioso.net>.
Hi Cathy,
> 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
"don't wish to see" is a bit more than I intended to express. I don't
think that the *HC* *repository* is the right place for such code. If
it's OK for you and IBM, you could for example attach that part of the
code to a JIRA issue, and we would point interested parties there. We
could also run the code through the IP clearance, so that other projects
at Apache can use it without further ado. In particular, I assume that
Harmony[1] could make good use of such a contribution. They have
to deal with native and platform specific code anyway, so that is not
an additional burden to them. Some IBMers are also active there.
[1] http://harmony.apache.org/
> 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.
That seems to be the best strategy to go forward. What you will
probably need is a plugin point where a hash is computed from the
username/password/domain data. Windows will not give you the
password in clear text, you'll only get the precomputed hash (iirc).
So the API needs to be callable with actual credentials, in which
case the hash is computed from the data. And it needs to be callable
without credentials, in which case the hash is obtained through a
native call. We can help you with the API design, but I won't be
able to contribute code in this area since I had a look at the
SUN Java code for NTLM authentication a few years ago. That doesn't
match the clean room requirements.
> IBM is usually pretty good about contributing back to open source.
Yes, processes obviously have improved a lot since I last had to do
with them. At the time, there was nothing short of starting a new
project worth several person-years that would have justified the
effort of getting the approval to contribute anything at all :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Cathy L Kegley <ck...@us.ibm.com>.
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)
ckegley@us.ibm.com
From: Oleg Kalnichevski <ol...@apache.org>
To: HttpComponents Project <de...@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/%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
Re: NTLMv2 in Apache HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2008-03-05 at 20:50 +0100, Roland Weber wrote:
> Oleg Kalnichevski wrote:
> >
> > A _consistent_, _ASF wide policy_ on the use of LGPL licensed code
>
> The current policy is "talk to the legal guys" :-)
>
And ain't that lovely?
> >> 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.
>
> I missed that when I recently visited their site.
> Thanks for the reminder.
>
>
> > Roland, you cannot expect a community to form around such a small code
> > base with such a narrow scope.
>
> A clean room (client) NTLM implementation (in Java) with native calls
> for Windows integration, that was the suggestion. We could use a Java
> NTLM implementation, Harmony could use it, MINA seems to be getting
> into protocols as well. jCIFS could use it too. To unit-test the code,
> it is basically necessary to implement the server side as well. That
> could make it interesting for Tomcat.
> Windows integration brings in a native element, so developers have to
> set up a C/C++ compiler anyway. At this point, it isn't a far jump to
> implement the (client) NTLM protocol in C as well, since both protocol
> and programming skills are there. Then add the non-Windows integrated
> authentication I mentioned in the previous mail, and you have an
> interesting proposal for commercial Linux distributions that want to
> sell their desktops into accounts with heterogeneous environments:
> Firefox automatically logging into an NTLM authentication proxy while
> running on a Linux platform.
> While we're at it, there might be some people interested in a Mono
> implementation. See logging.apache.org for an example of a project
> that solves a common problem across various programming languages.
>
>
> > Is there a community around HttpConn code?
>
> No. But HttpConn doesn't put additional requirements on development
> environments, OS platforms, or programming skills. Is there a community
> around HttpNIO? That was supposed to be just a few extra classes too,
> and it's now accounting for about half the traffic on our dev lists
> (perceived).
I guess that pretty much answers your question. As much as I consider
benefits of NIO greatly overrated, let's face the facts: interest in
HttpCore NIO has been driving most of the recent contributions to the
project.
> It does require additional programming skills, and it
> did add requirements to the development environment when we were still
> on Java 1.4 and you introduced HttpNIOSSL depending on Java 5. I surely
> stated my preference for a separate NIO component at the time.
>
> > We do not even know what code IBM is prepared to donate at this point,
> > if any at all.
>
> We do know that one of the two things that Cathy proposed is a platform
> specific feature. We have always denied requests for platform specific
> features. That native code is required is a guess of mine, but a likely one.
> Native code and/or Windows integration means a fundamentally different
> development environment from what we have now. If you feel we should
> change our views on that, you are welcome to start a discussion upfront.
> Until that discussion starts, I consider HC a project that is pure Java
> and cross-platform. And I will not mislead any potential contributors
> into believing that this is a good place to bring in platform specific
> features that are likely to require native code.
>
> > Your threats of vetoing contributions achieve nothing but
> > driving potential contributors away.
>
> Firstly, I'm not threatening anything. The Jakarta decisions page says:
> "Voters intending to veto an action item should make their opinions
> known to the group immediately so that the problem can be remedied
> as early as possible."
> I'm making my opinion known as early as possible. It is my understanding
> of a fair and open discussion to raise issues as soon as I identify them,
> in this case before anyone gets their hopes up high based on wrong
> assumptions. If somebody else had adverted Cathy that platform specific
> features are not exactly our business, or if you hadn't completely ignored
> the issue when replying to the mail in which I raised it, I wouldn't have
> had to emphasise it in this fashion.
>
> Secondly, I don't intend to veto contributions. I intend to veto
> significant changes to the way this project is running being brought
> in through the back door. Platform specific features and native code
> inevitably require such changes. Discuss them openly and upfront, or
> tell people that there is a misfit. That is surely better than letting
> somebody put work into contributions that will be rejected, and also
> better than forcing unwelcome changes upon us with the argument that
> "we can't reject this contribution now".
>
IBM needs this code written one way or another regardless of what we
think about it. The question is _what exactly_ they will be willing to
donate to the project. And it is still up to us to decide _what exactly_
and in which form we will be willing to accept. However, talking stuff
like vetoing contributions makes it less likely IBM will be willing to
donate anything at all.
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
Re: NTLMv2 in Apache HttpClient
Posted by Roland Weber <os...@dubioso.net>.
Oleg Kalnichevski wrote:
>
> A _consistent_, _ASF wide policy_ on the use of LGPL licensed code
The current policy is "talk to the legal guys" :-)
>> 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.
I missed that when I recently visited their site.
Thanks for the reminder.
> Roland, you cannot expect a community to form around such a small code
> base with such a narrow scope.
A clean room (client) NTLM implementation (in Java) with native calls
for Windows integration, that was the suggestion. We could use a Java
NTLM implementation, Harmony could use it, MINA seems to be getting
into protocols as well. jCIFS could use it too. To unit-test the code,
it is basically necessary to implement the server side as well. That
could make it interesting for Tomcat.
Windows integration brings in a native element, so developers have to
set up a C/C++ compiler anyway. At this point, it isn't a far jump to
implement the (client) NTLM protocol in C as well, since both protocol
and programming skills are there. Then add the non-Windows integrated
authentication I mentioned in the previous mail, and you have an
interesting proposal for commercial Linux distributions that want to
sell their desktops into accounts with heterogeneous environments:
Firefox automatically logging into an NTLM authentication proxy while
running on a Linux platform.
While we're at it, there might be some people interested in a Mono
implementation. See logging.apache.org for an example of a project
that solves a common problem across various programming languages.
> Is there a community around HttpConn code?
No. But HttpConn doesn't put additional requirements on development
environments, OS platforms, or programming skills. Is there a community
around HttpNIO? That was supposed to be just a few extra classes too,
and it's now accounting for about half the traffic on our dev lists
(perceived). It does require additional programming skills, and it
did add requirements to the development environment when we were still
on Java 1.4 and you introduced HttpNIOSSL depending on Java 5. I surely
stated my preference for a separate NIO component at the time.
> We do not even know what code IBM is prepared to donate at this point,
> if any at all.
We do know that one of the two things that Cathy proposed is a platform
specific feature. We have always denied requests for platform specific
features. That native code is required is a guess of mine, but a likely one.
Native code and/or Windows integration means a fundamentally different
development environment from what we have now. If you feel we should
change our views on that, you are welcome to start a discussion upfront.
Until that discussion starts, I consider HC a project that is pure Java
and cross-platform. And I will not mislead any potential contributors
into believing that this is a good place to bring in platform specific
features that are likely to require native code.
> Your threats of vetoing contributions achieve nothing but
> driving potential contributors away.
Firstly, I'm not threatening anything. The Jakarta decisions page says:
"Voters intending to veto an action item should make their opinions
known to the group immediately so that the problem can be remedied
as early as possible."
I'm making my opinion known as early as possible. It is my understanding
of a fair and open discussion to raise issues as soon as I identify them,
in this case before anyone gets their hopes up high based on wrong
assumptions. If somebody else had adverted Cathy that platform specific
features are not exactly our business, or if you hadn't completely ignored
the issue when replying to the mail in which I raised it, I wouldn't have
had to emphasise it in this fashion.
Secondly, I don't intend to veto contributions. I intend to veto
significant changes to the way this project is running being brought
in through the back door. Platform specific features and native code
inevitably require such changes. Discuss them openly and upfront, or
tell people that there is a misfit. That is surely better than letting
somebody put work into contributions that will be rejected, and also
better than forcing unwelcome changes upon us with the argument that
"we can't reject this contribution now".
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: NTLMv2 in Apache HttpClient
Posted by Roland Weber <os...@dubioso.net>.
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
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. 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.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NTLMv2 in Apache HttpClient
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2008-03-02 at 09:16 +0100, Roland Weber wrote:
> Hi Cathy, Oleg,
>
> please apologize my dropping a bit of salt into the soup.
>
> Oleg Kalnichevski wrote:
> > On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wrote:
> >> Hi Oleg,
> >>
> >
> > Hi Cathy
> >
> >> I am investigating what it would take to add NTLMv2 support to the Apache
> >> HttpClient as well as integrated Windows authentication for both NTLMv1
> >> and v2. I have seen your name on numerous messages in the forum
> >> regarding NTLM, so thought I write you. Is this support something you
> >> would be interested to see contributed back to the HttpClient? What are
> >> the restrictions on this?
> >
> > Absolutely. We would love to see a better support for NTLMv2 in
> > HttpClient.
>
> Yes, we would love to see better support for NTLMv2 in HttpClient.
> But what we would not want to see is somebody dropping a huge block
> of code on us without giving further support. There will be user
> questions on how things work or why they don't, and there will be
> bugs that need fixing.
Roland
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.
> Will there also be developers staying with
> the code to answer those questions and fix those bugs?
> As far as I can tell, the OSS expertise around NTLM currently resides
> at Samba/jCIFS. That's why our thoughts revolved around using jCIFS:
> we wouldn't need to become NTLM experts ourselves.
>
We have been waiting several years for an approval to depend on LGPL
libraries. How long do you suggest we should wait?
> 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?
> 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.
Oleg
> cheers,
> Roland
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-general/200802.mbox/%3c47A744CD.2030705@wstoddard.com%3e
> [2] http://www.apache.org/foundation/how-it-works.html#management
> [3]
> http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator
>
>
>
> ---------------------------------------------------------------------
> 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
Re: NTLMv2 in Apache HttpClient
Posted by Roland Weber <os...@dubioso.net>.
Hi Cathy, Oleg,
please apologize my dropping a bit of salt into the soup.
Oleg Kalnichevski wrote:
> On Wed, 2008-02-27 at 15:18 -0800, ckegley@us.ibm.com wrote:
>> Hi Oleg,
>>
>
> Hi Cathy
>
>> I am investigating what it would take to add NTLMv2 support to the Apache
>> HttpClient as well as integrated Windows authentication for both NTLMv1
>> and v2. I have seen your name on numerous messages in the forum
>> regarding NTLM, so thought I write you. Is this support something you
>> would be interested to see contributed back to the HttpClient? What are
>> the restrictions on this?
>
> Absolutely. We would love to see a better support for NTLMv2 in
> HttpClient.
Yes, we would love to see better support for NTLMv2 in HttpClient.
But what we would not want to see is somebody dropping a huge block
of code on us without giving further support. There will be user
questions on how things work or why they don't, and there will be
bugs that need fixing. Will there also be developers staying with
the code to answer those questions and fix those bugs?
As far as I can tell, the OSS expertise around NTLM currently resides
at Samba/jCIFS. That's why our thoughts revolved around using jCIFS:
we wouldn't need to become NTLM experts ourselves.
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.
Please note that we cannot make releases that depend on incubating
code, so we would have to wait for the podling to graduate before
making use of the functionality. On graduation from the Incubator,
HC seems to be a natural fit.
I know that IBM is aware of this problem and has procedures in
place to prevent code drops.[1] I'm just mentioning it so the
other folks in this discussion are aware of it, too. Getting
through the approval process for OSS code donations within IBM
is a major hurdle in itself :-)
Cathy, your suggestion involves two items. The first one is
support for NTLMv2 in pure Java. It can be considered an extension
of the current NTLMv1 support in HttpClient 3.1, though of course
we'd add it only to the 4.0 codebase. The second is integrated
Windows authentication. That means native (C/C++?) and platform
specific code.
Apache is a do-ocracy.[2] I don't have time to spend on NTLM and
therefore will mostly keep out of this discussion. If others are
OK with a code donation rather than an Incubator podling for the
first pure-Java item, that's OK with me too. But the platform
specific and native (non-Java) code required for integrated Windows
authentication MUST pass through the Incubator and create a
self-sustaining developer community before joining HC. Maybe
it is possible to find some people interested in implementing
integrated authentication for Mac and Linux. You'll need two
non-IBM committers to meet graduation requirements.[3]
A question that remains is whether it makes sense to duplicate
the efforts of the Samba team at Apache.
cheers,
Roland
[1]
http://mail-archives.apache.org/mod_mbox/incubator-general/200802.mbox/%3c47A744CD.2030705@wstoddard.com%3e
[2] http://www.apache.org/foundation/how-it-works.html#management
[3]
http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org