Re: NTLMv2 in Apache HttpClient
On 08.03.2008, at 12:46, Oleg Kalnichevski wrote: On Sat, 2008-03-08 at 09:18 +0100, Roland Weber wrote: Hi Oleg, With all due respect, our requirements or _your_ requirements? Read my previous post: 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. cheers, Roland There is no mentioning of 'pure' Java, whatever that means, in our charter. This is your personal interpretation of the charter. That is the _whole_ point. I've to admit that I deliberately stayed out of this discussion for several reasons but now that the thread cooled down a bit I'll give my 2 cents... First of all, there's no one rushing or pushing things in through the back-door, as far as I can see it's all here on [EMAIL PROTECTED] Secondly, we really shouldn't limit the possibilities of HC in such a strong fashion. As long as there are contributors, interest and no legal hurdles we should be welcoming and open for additions, be it pure Java or something else, perhaps platform-specific. And fwiw, we do not have to think in terms of actual releases. There's the possibility of using 'contrib' or even 'sub- projects' (given there's enough interest etc.) - there's also sufficient precedent here at the ASF so that we do not have to feel uncomfortable doing that (e.g. take a look at ApacheMonitor.exe in HTTPD-land/-ville). And finally, note that we're still only discussing theoretical things; please, let's take a deep breath and wait until there's something concrete on the table... Thanks for listening! Cheers, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
On Sat, 2008-03-08 at 09:18 +0100, Roland Weber wrote: > Hi Oleg, > > > With all due respect, our requirements or _your_ requirements? > > Read my previous post: > > > 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. > > cheers, >Roland > There is no mentioning of 'pure' Java, whatever that means, in our charter. This is your personal interpretation of the charter. That is the _whole_ point. cheers Oleg > > - > 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]
Re: NTLMv2 in Apache HttpClient
Hi Cathy, If the 3.1 code base doesn't have the support to handle connection-based authentication states, how does NTLMv1 work? Is the NTLMv1 implementation in 3.1 datagram-oriented as opposed to connection-based? No, it's connection-based. We just don't track the state. If a connection is returned to the pool after NTLM authentication, it will be handed out to any thread connecting to the same target, even if that thread does not have access to the credentials it would need to authenticate a new connection. This approach really works only if the connection pool is owned by a single client application. If it's a shared pool, NTLM authenticated connections need to be closed or there is a gaping security hole. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
Hi Oleg, With all due respect, our requirements or _your_ requirements? Read my previous post: 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. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
On Thu, 2008-03-06 at 08:31 +0100, [EMAIL PROTECTED] wrote: > Hi Oleg, > > >_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. > > And the sooner they know of our requirements, the > cheaper it will be for them to implement something > that fits within our project. With all due respect, our requirements or _your_ requirements? > If you wait until > they have code that already addresses all their > customer requirements, and then ask them to > spend more time on fitting it for us, that's when > you loose a potential contributor. > > >_However, talking stuff > >_like vetoing contributions makes it less likely IBM will be willing to > >_donate anything at all. > > No it doesn't. It sets clear guidelines that they > can take into account from the start with little > effort. Same as above. Oleg > It's sad that I had to mention a veto, but > I will not have this issue ignored, or forced a > rush decision on us later when we are facing a > contribution that inseparably mingles functionality > we would like to use and such that doesn't fit at > all into our project. I will rather have a discussion > *now*, so I don't have to reject the contribution > when it is offered. > > 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]
Re: NTLMv2 in Apache HttpClient
Hi Roland, If the 3.1 code base doesn't have the support to handle connection-based authentication states, how does NTLMv1 work? Is the NTLMv1 implementation in 3.1 datagram-oriented as opposed to connection-based? Cathy Kegley From: [EMAIL PROTECTED] To: Date: 03/06/2008 01:50 AM Subject: Re: NTLMv2 in Apache HttpClient Hi Cathy, > who can I work with to make sure my solution is > something both IBM and Apache are happy with? at Apache, all design discussions happen on the public mailing lists. For HC, that is this mailing list. I understand that you cannot provide code for review until you've run through your approval process. But you can still discuss with us on a non-code level in the public. I will know on which items I should not comment. > 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.) I won't have the connection management ready to handle connection-based authentication state by then, but we don't have that in the 3.1 codebase either :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
Hi Cathy, > who can I work with to make sure my solution is > something both IBM and Apache are happy with? at Apache, all design discussions happen on the public mailing lists. For HC, that is this mailing list. I understand that you cannot provide code for review until you've run through your approval process. But you can still discuss with us on a non-code level in the public. I will know on which items I should not comment. > 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.) I won't have the connection management ready to handle connection-based authentication state by then, but we don't have that in the 3.1 codebase either :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
Hi Oleg, >_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. And the sooner they know of our requirements, the cheaper it will be for them to implement something that fits within our project. If you wait until they have code that already addresses all their customer requirements, and then ask them to spend more time on fitting it for us, that's when you loose a potential contributor. >_However, talking stuff >_like vetoing contributions makes it less likely IBM will be willing to >_donate anything at all. No it doesn't. It sets clear guidelines that they can take into account from the start with little effort. It's sad that I had to mention a veto, but I will not have this issue ignored, or forced a rush decision on us later when we are facing a contribution that inseparably mingles functionality we would like to use and such that doesn't fit at all into our project. I will rather have a discussion *now*, so I don't have to reject the contribution when it is offered. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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 dona
Re: NTLMv2 in Apache HttpClient
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) [EMAIL PROTECTED] From: Roland Weber <[EMAIL PROTECTED]> To: HttpComponents Project 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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
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, bu
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
Re: NTLMv2 in Apache HttpClient
On 03/03/2008, Roland Weber <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
On 03/03/2008, Roland Weber <[EMAIL PROTECTED]> 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/[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. 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 t
Re: NTLMv2 in Apache HttpClient
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/[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. 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 ch
Re: NTLMv2 in Apache HttpClient
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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, [EMAIL PROTECTED] 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/[EMAIL > PROTECTED] > [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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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, [EMAIL PROTECTED] 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/[EMAIL PROTECTED] [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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 [EMAIL PROTECTED] > > list > > already? > > Yep, I'm subscribed to legal-discuss@ and [EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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 [EMAIL PROTECTED] list already? Yep, I'm subscribed to legal-discuss@ and [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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 [EMAIL PROTECTED] 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) > [EMAIL PROTECTED] > > 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 > <[EMAIL PROTECTED]> > > To: > > HttpComponents Project > > > Cc: > > Cathy L Kegley/Austin/[EMAIL PROTECTED] > > 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) > > [EMAIL PROTECTED] > > > > Inactive hide details for Oleg Kalnichevski ---02/28/2008 04:40:55 > > AM---On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] wOleg > > Kalnichevski ---02/28/2008 04:40:55 AM---On Wed, 2008-02-27 at 15:18 > > -0800, [EMAIL PROTECTED] wrote: > > > > > > From: > > > > Oleg Kalnichevski > > <[EMAIL PROTECTED]> > > > > To: > > > > Cathy L Kegley/Austin/[EMAIL PROTECTED] > > > > Cc: > > > > HttpComponents Project > > > > > > Date: > > > > 02/28/2008 04:40 AM > > > > Subject: > > > > Re: NTLMv2 in Apache HttpClient > > > > > > > __ > > > > > > > > > > On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] 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 > > thes
Re: NTLMv2 in Apache HttpClient
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) [EMAIL PROTECTED] From: Oleg Kalnichevski <[EMAIL PROTECTED]> To: HttpComponents Project Cc: Cathy L Kegley/Austin/[EMAIL PROTECTED] 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) > [EMAIL PROTECTED] > > Inactive hide details for Oleg Kalnichevski ---02/28/2008 04:40:55 > AM---On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] wOleg > Kalnichevski ---02/28/2008 04:40:55 AM---On Wed, 2008-02-27 at 15:18 > -0800, [EMAIL PROTECTED] wrote: > > > From: > > Oleg Kalnichevski > <[EMAIL PROTECTED]> > > To: > > Cathy L Kegley/Austin/[EMAIL PROTECTED] > > Cc: > > HttpComponents Project > > > Date: > > 02/28/2008 04:40 AM > > Subject: > > Re: NTLMv2 in Apache HttpClient > > > __ > > > > > On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] 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
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) > [EMAIL PROTECTED] > > Inactive hide details for Oleg Kalnichevski ---02/28/2008 04:40:55 > AM---On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] wOleg > Kalnichevski ---02/28/2008 04:40:55 AM---On Wed, 2008-02-27 at 15:18 > -0800, [EMAIL PROTECTED] wrote: > > > From: > > Oleg Kalnichevski > <[EMAIL PROTECTED]> > > To: > > Cathy L Kegley/Austin/[EMAIL PROTECTED] > > Cc: > > HttpComponents Project > > > Date: > > 02/28/2008 04:40 AM > > Subject: > > Re: NTLMv2 in Apache HttpClient > > > __ > > > > > On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMv2 in Apache HttpClient
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) [EMAIL PROTECTED] From: Oleg Kalnichevski <[EMAIL PROTECTED]> To: Cathy L Kegley/Austin/[EMAIL PROTECTED] Cc: HttpComponents Project Date: 02/28/2008 04:40 AM Subject: Re: NTLMv2 in Apache HttpClient On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] 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
On Wed, 2008-02-27 at 15:18 -0800, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
