Re: Windows SSPI Schannel implementation ready
Am 13.06.2012 20:51, schrieb Yang Tse: Daniel Stenbergdan...@haxx.se wrote: I assume you meant that to be --with-winssl? That seems more like regular configure style. (It is also done more or less automatically with the use of autoconf macros.) Done. Just pushed. Great, thanks Yang! 1st autobuild with new option: http://curl.haxx.se/dev/log.cgi?id=20120614071403-7256 Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Gün, 1st autobuild with new option: http://curl.haxx.se/dev/log.cgi?id=20120614071403-7256 Great!. I've already pushed some further Schannel polishing, so next Schannel autobuilds should come out 'cleaner'. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi all, Get well soon. Thank you for the well wishes - I got a good night's sleep but am still feeling pretty crap this morning :( I'm dosed up on Ibuprofen at the moment to try and reduce the fever but I might have to nip out in a bit and grab some paracetamol based cold and flue type remedies. As Gün sugested SSL-Windows-native or WinSSL without version number information. But, only when actually using Windows SSL implementation. Unless I'm wrong, that is when schannel is in use not simply when SSPI is used. I'm not opposed to not including the version number - this would be consistent to what WinIDN displays, however, I also think including the version number would also be consistent with all the other libraries that we display. I know this is a community effort but perhaps some direction from Daniel and whether the version number, as a rule of thumb, should be included for all items in the version string or not is needed here. I also think, as per the discussion I started 6 weeks ago which I thought we had decided to do, hence my work here, was that the package name WinSSPI, Windows SSPI or SSPI-Windows-native should be displayed for the other features that SSPI offers not just the SChannel SSL support - again this is synonymous to the other Security Providers that curl uses and provides consistency. The inclusion of SSPI in curl has obviously changed a fair amount since it was first included as a feature and that was why I recommended including it in the version string back in April and moving to a scenario where SSPI isn't listed in the features list ;-) For API compatibility we have decided to keep it in the features list as well as listing it in the package / version string. If this is something that you had a strong opinion on, and I'm still not sure if it is or not, then why didn't you let us know 6 weeks ago before I spent two days doing the rework and learning curl's makefiles when I didn't need to. Mostly library version number given for a system library. I don't have an issue with that, whilst others Guenter, Marc, Gisle et all don't seem to mind either. The only possible objection I have is... that version.lib is currently being linked to statically and if that is a problem for running curl on 12-year old+ versions of Windows then we *should* consider dynamically including it like we do with secur32.dll for example. S. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Steve Holme steve_ho...@hotmail.com wrote: I'm not opposed to not including the version number - this would be consistent to what WinIDN displays, [...] Ok, then we have consensus then. I also think, as per the discussion I started 6 weeks ago which I thought we had decided to do, hence my work here, was that the package name WinSSPI, Windows SSPI or SSPI-Windows-native should be displayed for the other features that SSPI offers not just the SChannel SSL support - again this is synonymous to the other Security Providers that curl uses and provides consistency. I asked for a patch april 23. http://curl.haxx.se/mail/lib-2012-04/0259.html It has not been provided until june 10. http://curl.haxx.se/mail/lib-2012-06/0111.html One of the reasons for which I personally dislike big patches is that these usually hide changes which are not properly discussed, or discussed with such lengthy threads that no one knows finally what's going on, making it necessary to fully analyze resulting patch in order to know what changes it really introduces. This is what I'm doing now. I might have further objections, so don't be surprised if I mention or fix something else. Given that it seems we've reached consensus on that you can live without the numeric part of the string, and that I can live with some schannel specific identifier, I'm pushing right now a patch with the following commit message: schannel: remove version number and identify its use with 'schannel' literal Version number is removed in order to make this info consistent with how we do it with other MS and Linux system libraries for which we don't provide this info. Identifier changed from 'WinSSPI' to 'schannel' given that this is the actual provider of the SSL/TLS support. libcurl can still be built with SSPI and without SCHANNEL support. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hello everyone, 2012/6/13 Yang Tse yangs...@gmail.com: One of the reasons for which I personally dislike big patches is that these usually hide changes which are not properly discussed, or discussed with such lengthy threads that no one knows finally what's going on, making it necessary to fully analyze resulting patch in order to know what changes it really introduces. This is what I'm doing now. I might have further objections, so don't be surprised if I mention or fix something else. This is why I posted the full commit history during the early development stages and especially separated even squashed commits to avoid mixing up changes to different areas. While you say that an updated patch wasn't provided until June, the other changes have been around since April and the full commit history including separate small patches was available from the beginning. The new changes introducing the updated version information were also separated and can be easily identified in the history. Given that it seems we've reached consensus on that you can live without the numeric part of the string, and that I can live with some schannel specific identifier, I'm pushing right now a patch with the following commit message: schannel: remove version number and identify its use with 'schannel' literal Version number is removed in order to make this info consistent with how we do it with other MS and Linux system libraries for which we don't provide this info. Identifier changed from 'WinSSPI' to 'schannel' given that this is the actual provider of the SSL/TLS support. libcurl can still be built with SSPI and without SCHANNEL support. Actually schannel is not the correct identifier. It's either Schannel or Secure Schannel. Please take a look at the MSDN documentation before doing such changes: http://msdn.microsoft.com/en-us/library/windows/desktop/ms678421.aspx I see that you changed the winbuild scripts to automatically set USE_SSPI to yes and USE_SCHANNEL to true if USE_SSL is false. Why did you do that? That makes it impossible to build a Windows version without SSL support. Before your changes Schannel was only enabled if SSPI was enabled and OpenSSL was not. Besides that, I liked the idea of having the low level Windows libaries in a separate WINLIBS variable in the makefile. Why did you revert this cleanup change, too? Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi, Am 13.06.2012 16:40, schrieb Yang Tse: One of the reasons for which I personally dislike big patches is that these usually hide changes which are not properly discussed, or discussed with such lengthy threads that no one knows finally what's going on, making it necessary to fully analyze resulting patch in order to know what changes it really introduces. This is what I'm doing now. I might have further objections, so don't be surprised if I mention or fix something else. but then we did make a mistake: we saw this huge patch coming, and it was then wrong to encorage Marc to work further in his fork until its ready - instead we should have granted him commit rights and told him to push his changes one by one right after the last release. just my 2ct. Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi Yang, I'm not opposed to not including the version number - this would be consistent to what WinIDN displays, [...] Ok, then we have consensus then. On the version number yes, on the SChannel literal no as this should be SSPI - you wouldn't list either libssl32 or libeay32 for OpenSSL !! I also think, as per the discussion I started 6 weeks ago which I thought we had decided to do, hence my work here, was that the package name WinSSPI, Windows SSPI or SSPI-Windows-native should be displayed for the other features that SSPI offers not just the SChannel SSL support - again this is synonymous to the other Security Providers that curl uses and provides consistency. I asked for a patch april 23. http://curl.haxx.se/mail/lib-2012-04/0259.html As Marc has already mentioned the commit history of the original work has been available for a long time now. My rework has been available since the 22nd April. The work you reverted on the 23 April was made because of some points over SSPI vs SSO #defines and not the version number rework itself - these issues were then addressed on the forums between the 13 May and the 16 May - no additional input was provided by you during that conversation. Given that it seems we've reached consensus on that you can live without the numeric part of the string, and that I can live with some schannel specific identifier, I'm pushing right now a patch with the following commit message: schannel: remove version number and identify its use with 'schannel' literal This is the exact opposite of what I have been saying - Windows SSPI is a provider of security features like GNUTLS is and should be recognised as such. Like you also said we don't list the individual features in the package / version string so why list SChannel on its own? Identifier changed from 'WinSSPI' to 'schannel' given that this is the actual provider of the SSL/TLS support. libcurl can still be built with SSPI and without SCHANNEL support. I will have a look at the change you are putting in but from reading your reply here, you seem to have completely ignored everything I have said on this matter and any contribution I have made. I have provided good argument for including Windows SSPI as the package name and for the inclusion in the version string for both SChannel based SSL and for without. I have had agreement from others here and to that degree I can only conclude that you simple do what you want when you don't agree with what has been said. In that respect I can only thank you for wasting my time on this - 2 days of development and several hours of emails. Steve --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Folks, to shorten this never-ending discussion I did just change the string to SSL-Windows-native for 3 reasons: 1) this describes how SSL is supported in a way the average user understands; schannel is something which users might not even know about what it is at all. 2) It is conform with what we show as version when we build with native IDN support. 3) At least we have 2 of us agree on this (me and Marc). TODOs: 1) we should make sure this string appears *only* if SSL functionality is provided via schannel, sspi, whatever ... 2) it should remain possible to build with SSPI auth stuff and without native SSL stuff - we need still *two* defines 3) SSPI listed as feature if enabled must remain (as Daniel stated), and it should also be possible to build with SSL-native but without SSPI auth stuff. 4) we should should make sure that this SSL-native support is called equal allover the project files, f.e. WINSSL (- makefiles) 5) we need to teach configure to build with SSL-native; I propose: --winssl OT, but in the same context: we need also such an option for IDN-native, I propose here: --winidn please lets concentrate on these things now so that we can soon start to add some autobuilds for the new stuff! Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
On Wed, 13 Jun 2012, Guenter wrote: 5) we need to teach configure to build with SSL-native; I propose: --winssl I assume you meant that to be --with-winssl? That seems more like regular configure style. (It is also done more or less automatically with the use of autoconf macros.) we need also such an option for IDN-native, I propose here: --winidn --with-winidn? please lets concentrate on these things now so that we can soon start to add some autobuilds for the new stuff! Thanks for this Guenter. I am still interested to hear what issues or debates we have left to sort out after Guenter's points have been addressed. I'm thinking we could try to have a vote about the issues that we can't reach consensus on. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Am 13.06.2012 20:24, schrieb Daniel Stenberg: On Wed, 13 Jun 2012, Guenter wrote: 5) we need to teach configure to build with SSL-native; I propose: --winssl I assume you meant that to be --with-winssl? That seems more like yup, of course! sorry ... regular configure style. (It is also done more or less automatically with the use of autoconf macros.) we need also such an option for IDN-native, I propose here: --winidn --with-winidn? sure. Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi Guenter, to shorten this never-ending discussion I did just change the string to SSL-Windows-native for 3 reasons: [...] 3) At least we have 2 of us agree on this (me and Marc). Three (me) - I was simply against the package name as SChannel, although Marc, Yang and I didn't have a problem with the string WinSSPI although what you suggested is consistent with the IDN string and people that know me, know I have an issue with consistency ;-) TODOs: 1) we should make sure this string appears *only* if SSL functionality is provided via schannel, sspi, whatever ... I still think it is worth having the string there when SSPI is included when it compiled in security context mode / SSO (auth stuff as you call it) as it is using the same library. For example, you don't remove the libssh string when it isn't compiled with zlib ;-) I slight bad analogy but hopefully you understand my point there. Now without checking email history yet again, and to be honest I am just about out of patients on this, considering the amount of time and effort I have already put into it, I thought Marc and Daniel agreed here. 2) it should remain possible to build with SSPI auth stuff and without native SSL stuff - we need still *two* defines I'm a little confused here... are you talking about makefile options or the USE_* #defines or something else? In Visual Studio I had curl building with 1) Just the security context / SSO capabilities and 2) These plus SChannel SSL with last night's version of the code base - I haven't rebuilt todays changes so I don't know if something has changed to affect that. USE_WINDOWS_SSPI should build just the security context / SSO capabilities. USE_WINDOWS_SSPI and USE_SCHANNEL should additionally build in the SChannel SSL stuff. Kind Regards Steve --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Daniel Stenberg dan...@haxx.se wrote: I assume you meant that to be --with-winssl? That seems more like regular configure style. (It is also done more or less automatically with the use of autoconf macros.) Done. Just pushed. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Marc Hoersken i...@marc-hoersken.de wrote: Identifier changed from 'WinSSPI' to 'schannel' given that this is the actual provider of the SSL/TLS support. libcurl can still be built with SSPI and without SCHANNEL support. Actually schannel is not the correct identifier. It's either Schannel or Secure Schannel. Please take a look at the MSDN documentation before doing such changes: http://msdn.microsoft.com/en-us/library/windows/desktop/ms678421.aspx Personally I don't care how we call it as long as the literal that we use to identify that SSL is provided by MS libraries does not include the 'SSPI' literal. For the reasons I've given in my previous mail and commit message. OTOH every half baked Windows user, and all power-users, knows that schannel is the 'thingy' to hack in the registry to modify SSL behavior. But I have no problem with calling it 'SSL-Windows-native'. I see that you changed the winbuild scripts to automatically set USE_SSPI to yes and USE_SCHANNEL to true if USE_SSL is false. Why did you do that? That makes it impossible to build a Windows version without SSL support. Before your changes Schannel was only enabled if SSPI was enabled and OpenSSL was not. Fixed now. define USE_WINSSL to build with both SSPI and schannel support. Besides that, I liked the idea of having the low level Windows libaries in a separate WINLIBS variable in the makefile. Why did you revert this cleanup change, too? Because in order to use debug and release versions of windows libs it is easier to keep it as it was previously. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Yang, OTOH every half baked Windows user, and all power-users, knows that schannel is the 'thingy' to hack in the registry to modify SSL behavior. But I have no problem with calling it 'SSL-Windows-native'. Personally I find that quite offensive. I have been programming Windows since v2.0 and have used SSPI on a number of occasions for Security Contexts but not actually used SChannel. I might have read about it and glossed over it but as a software engineer and power user I wasn't aware of its usage fully until Marc's work. I have stated time and time again that the literal should include SSPI because, as I understand it, and please correct me if I am wrong and point me to the MSDN documentation but SSPI is the interface to all the services that it provides. Kind Regards Steve --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Steve Holme steve_ho...@hotmail.com wrote: I'm not opposed to not including the version number - this would be consistent to what WinIDN displays, [...] Ok, then we have consensus then. On the version number yes, on the SChannel literal no as this should be SSPI - you wouldn't list either libssl32 or libeay32 for OpenSSL !! Nope. libcurl can be built with SSPI support using other SSL libraries as it has been done up to nowadays. And this is one of the things that must be kept around. I also think, as per the discussion I started 6 weeks ago which I thought we had decided to do, hence my work here, was that the package name WinSSPI, Windows SSPI or SSPI-Windows-native should be displayed for the other features that SSPI offers not just the SChannel SSL support - again this is synonymous to the other Security Providers that curl uses and provides consistency. I asked for a patch april 23. http://curl.haxx.se/mail/lib-2012-04/0259.html As Marc has already mentioned the commit history of the original work has been available for a long time now. My rework has been available since the 22nd April. The work you reverted on the 23 April was made because of some points over SSPI vs SSO #defines and not the version number rework itself - these issues were then addressed on the forums between the 13 May and the 16 May - no additional input was provided by you during that conversation. Given that no answer, neither with patch nor without it, to my april 23 mail requesting a patch was given by any of you. I lost any interest in any development that was going outside of libcurl repo. Assuming that the time would come when you would bring all that work either as a patch or somehow and that would be the moment to review it. schannel: remove version number and identify its use with 'schannel' literal This is the exact opposite of what I have been saying - Windows SSPI is a provider of security features like GNUTLS is and should be recognised as such. Like you also said we don't list the individual features in the package / version string so why list SChannel on its own? Because it is the one thanks to which SSL works on Windows. As an exercise remove schannel.dll and you'll see that SSL stops working. MS loves to put layers and layers in between things. SSPI is a 'user' of schannel, the same as many other windows parts. Identifier changed from 'WinSSPI' to 'schannel' given that this is the actual provider of the SSL/TLS support. libcurl can still be built with SSPI and without SCHANNEL support. I will have a look at the change you are putting in but from reading your reply here, you seem to have completely ignored everything I have said on this matter and any contribution I have made. I really appreciate every one's work. The fact that it might need some adjustments doesn't imply the contrary. I have provided good argument for including Windows SSPI as the package name and for the inclusion in the version string for both SChannel based SSL and for without. I have had agreement from others here and to that degree I can only conclude that you simple do what you want when you don't agree with what has been said. In that respect I can only thank you for wasting my time on this - 2 days of development and several hours of emails. Hmmm, when you calm down and read this when some time passes by you might realize how groundless this last paragraph is. Good luck and get well soon. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
On 13 Jun 2012, at 16:04, Marc Hoersken wrote: Actually schannel is not the correct identifier. It's either Schannel or Secure Schannel. Please take a look at the MSDN documentation before doing such changes: http://msdn.microsoft.com/en-us/library/windows/desktop/ms678421.aspx I've never done any secure network coding on Windows at this level, but where you put “Secure Schannel” did you mean to type “Secure Channel”? cf. http://msdn.microsoft.com/en-us/library/windows/desktop/aa380123(v=vs.85).aspx I think users would expect to see the name “Schannel”. SSPI is Microsoft's proprietary variant of GSSAPI. -- Tim Bannister – is...@jellybaby.net smime.p7s Description: S/MIME cryptographic signature --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Steve Holme steve_ho...@hotmail.com wrote: OTOH every half baked Windows user, and all power-users, knows that schannel is the 'thingy' to hack in the registry to modify SSL behavior. But I have no problem with calling it 'SSL-Windows-native'. Personally I find that quite offensive. I have been programming Windows since v2.0 and have used SSPI on a number of occasions for Security Contexts but not actually used SChannel. I might have read about it and glossed over it but as a software engineer and power user I wasn't aware of its usage fully until Marc's work. Why do you take my comment as something personal? I really don't understand this. I have stated time and time again that the literal should include SSPI because, as I understand it, and please correct me if I am wrong and point me to the MSDN documentation but SSPI is the interface to all the services that it provides. Hey, I'm not saying SSPI isn't the outer interface. I'm saying that we can build a libcurl version wich uses SSPI and makes no use of schannel. You want a MS link which speaks about schannel without mentioning SSPI? http://support.microsoft.com/kb/245030 -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
2012/6/13 Tim Bannister is...@jellybaby.net: On 13 Jun 2012, at 16:04, Marc Hoersken wrote: Actually schannel is not the correct identifier. It's either Schannel or Secure Schannel. Please take a look at the MSDN documentation before doing such changes: http://msdn.microsoft.com/en-us/library/windows/desktop/ms678421.aspx I've never done any secure network coding on Windows at this level, but where you put “Secure Schannel” did you mean to type “Secure Channel”? cf. http://msdn.microsoft.com/en-us/library/windows/desktop/aa380123(v=vs.85).aspx Yes, that was actually a typo on my end. Sorry for that. Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Guenter, 2012/6/12 Guenter li...@gknw.net: Hi Marc, Am 10.06.2012 22:54, schrieb Marc Hoersken: with the support of Steve and Guenter, I was able to ready my Windows SSPI Schannel implementation. naa, not worth to mention me at all - I did contribute nothing but few small commits! Great work, Marc! And thanks to Steve too who did also put a bunch of energy into it. Even small changes can have a huge impact for the success of such a project. You were a great help for me, especially with the build files. (if you're looking for something new to attack then take a look at libssh2 - perhaps its possible to provide the crypto stuff there too from Schannel; that would be very great since it would remove the dependecy to either openssl or libgcrypt ...) Yes, that's a good idea. I just looked at the libgcrypt.[ch] and openssl.[ch] files where and it seems like that small amount of code could be reimplemented using SSPI. I will have to check the availability of all the required crypto stuff, but even if SSPI does not provide them, the Windows CryptoAPI should. I will see then I get a chance to give it a try. Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
SSPI is already present in libcurl's feature list when in use, so... Why do we need to show the security.dll or secur32.dll version in libcurl's version string, and additionally dress it up as WinSSPI? These two are system libraries the same as all other system libs that might be used, such as kernel32, normaliz, wldap32 and ws2_32, for which we don't show any version info. The user/developer has very little choice relative to which version is used. Additionally showing that info introduces another library dependency which didn't exist up to now. My opinion is to get rid of it, unless someone tells us why we badly need it. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
2012/6/12 Yang Tse yangs...@gmail.com: SSPI is already present in libcurl's feature list when in use, so... Why do we need to show the security.dll or secur32.dll version in libcurl's version string, and additionally dress it up as WinSSPI? These two are system libraries the same as all other system libs that might be used, such as kernel32, normaliz, wldap32 and ws2_32, for which we don't show any version info. The user/developer has very little choice relative to which version is used. That is a very good point. Basically we do now show the Windows version, because that is what the security.dll/secur32.dll version is tied to. Additionally showing that info introduces another library dependency which didn't exist up to now. Also another good point. My opinion is to get rid of it, unless someone tells us why we badly need it. Since I am not the originator of the idea to change the version information and just had the SSPI interface version in my first schannel implementation being shown, just like the OpenSSL version, I do not have any strong opinion on this matter. It would be good if you (Daniel, Steve, Yang) could decide on what to do here. I do understand and support Yang's arguments, but I also understand that we need to figure out a good way to illustrate the features provided by SSPI or any other security provider. Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi Yang, On Tue, 12 Jun 2012, Yang Tse wrote: SSPI is already present in libcurl's feature list when in use, so... Why do we need to show the security.dll or secur32.dll version in libcurl's version string, and additionally dress it up as WinSSPI? There are two reasons for including Windows SSPI in the version information. 1) curl displays the SSL library in its version string and as such should display something when SSL through Windows SSPI is enabled. 2) Windows SSPI can be thought of as the equivalent to OpenSSL or better still GNUTLS as it is a provider of security related features and provides libcurl with the following: * SSL / TLS * Security Context Information such as Negotiate, Kerberos and NTLM * Obtaining the currently logged in Windows credentials - Single Sign On for the want of a better name From discussion with Daniel, and to a certain degree from your email of 23 April, I believe that the feature of SSPI as listed in curl's feature string actually represents the SSO capability of Windows SSPI and not everything that Windows SSPI provides (or at least it shouldn't represent all of SSPI as otherwise you wouldn't display GSS-Negotiate and NTLM for example). WinSSPI is a short friendly name, or package name if you like, for security.dll / secur32.dll just as OpenSSL is the package name for libssl32.dll and libeay32.dll. Originally, Mark had this as SChannel which we decided wasn't a good name. Other names that were briefly talked about were sspi, SSPI and WinSSPI - As such, WinSSPI seemed like the best choice ;-) These two are system libraries the same as all other system libs that might be used, such as kernel32, normaliz, wldap32 and ws2_32, for which we don't show any version info. I guess there is a fine line between what package and version information curl should show versus what it shouldn't and Windows muddies the water a little by provided low level libraries such as ws2_32.dll (Winsock 2) and other high level libraries that give the functionality of Windows SSPI or implement the LDAP protocol. For example, if we wanted to show what third party LDAP libraries curl might use, we could display OpenLDAP and Windows LDAP (the later would probably want to show the version number from wldap32.dll to be consistent), however, we don't want to show the information for low level libraries such as ws2_32.dll. The user/developer has very little choice relative to which version is used. This is very true... and I guess it would be similar to something like OpenSSL being pre-installed as part of Solaris for example ;-) I admit things are a little different in *nix land as other versions could be downloaded using the package manager / installed by the user. Additionally showing that info introduces another library dependency which didn't exist up to now. Again this is true and as you are aware, getting version information out of a dll on Windows requires using version.dll - As this was introduced as a system dll in Windows 2000 I don't have a problem with that or statically linking against it. However, I've only been part of the development team for the last 12 months, and don't have the wealth of experience that you do, so don't know the full history of the product and demographic of users and the variants of Windows that curl is used on - In that respect I honestly can't say if that is an issue or not. If we decide it is an issue then I would recommend that we bind to the dll dynamically thus allowing Curl_sspi_vesion() to fail gracefully and display WinSPPI/unknown (as it does now if any part of the function fails) or just WinSSPI if preferred. My opinion is to get rid of it, unless someone tells us why we badly need it. My own preference is to keep it because 1) It is in keeping with other security providers in curl, 2) Like any of the version / package information it is useful to know and 3) We need to display something in the SSL version string so if we were to ditch it what would we display here? Just my two pennies worth... Although that probably feels like two pound / dollar / euro / sheep / any other currencies worth after reading ;-) Steve --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi, 1st of all: I have no strong opinion either for or against the string ... Am 12.06.2012 19:21, schrieb Steve Holme: On Tue, 12 Jun 2012, Yang Tse wrote: 1) curl displays the SSL library in its version string and as such should display something when SSL through Windows SSPI is enabled. k, but the version info is surely not important - it would in this case equal to the Windows version, and we didnt display it before (nor did we f.e. for WinIDN), and we dont display the kernel version on Linux either. From discussion with Daniel, and to a certain degree from your email of 23 April, I believe that the feature of SSPI as listed in curl's feature string actually represents the SSO capability of Windows SSPI and not everything that Windows SSPI provides (or at least it shouldn't represent all of SSPI as otherwise you wouldn't display GSS-Negotiate and NTLM for example). but we DO display 'SSL' as a feature as well ... These two are system libraries the same as all other system libs that might be used, such as kernel32, normaliz, wldap32 and ws2_32, for which we don't show any version info. I guess there is a fine line between what package and version information curl should show versus what it shouldn't and Windows muddies the water a little by provided low level libraries such as ws2_32.dll (Winsock 2) and other high level libraries that give the functionality of Windows SSPI or implement the LDAP protocol. For example, if we wanted to show what third party LDAP libraries curl might use, we could display OpenLDAP and Windows LDAP (the later would probably want to show the version number from wldap32.dll to be consistent), however, we don't want to show the information for low level libraries such as ws2_32.dll. goot example for not adding a version info: up to now we dont show version info for any LDAP lib, and that although the user *has* a choice over wldap32 vs. OpenLDAP, NovellLDAP, MozillaLDAP ... The user/developer has very little choice relative to which version is used. true. Additionally showing that info introduces another library dependency which didn't exist up to now. Again this is true and as you are aware, getting version information out of a dll on Windows requires using version.dll - As this was introduced as a system dll in Windows 2000 I don't have a problem with that or statically linking against it. However, I've only been part of the development team for the last 12 months, and don't have the wealth of experience that you do, so don't know the full history of the product and demographic of users and the variants of Windows that curl is used on - In that respect I honestly can't say if that is an issue or not. If we decide it is an issue then I would recommend that we bind to the dll dynamically thus allowing Curl_sspi_vesion() to fail gracefully and display WinSPPI/unknown (as it does now if any part of the function fails) or just WinSSPI if preferred. My opinion is to get rid of it, unless someone tells us why we badly need it. well, perhaps a compromise would be if we just display SSL-Windows-native like we do with WinIDN ? That would drop the new dependency to the version lib while remaining the information that SSL is provided through a Windows system lib rather than through an expternal lib (same as with WinIDN). Here's an output of a build with WinIDN: curl 7.26.0 (x86_64-pc-win32) libcurl/7.26.0 OpenSSL/1.0.0j zlib/1.2.7 IDN-Windows-native libssh2/1.4.2 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN Largefile NTLM SSL SSPI libz Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Marc Hoersken i...@marc-hoersken.de wrote: I do understand and support Yang's arguments, but I also understand that we need to figure out a good way to illustrate the features provided by SSPI or any other security provider. The fact that security.dll or secur32.dll is being used is exposed for historical reasons as libcurl's 'SSPI' feature. Exposing capabilities in a finer grained way would imply exposing other 'feature' literals. for example 'SSO' could represent single-sign-on capability, which could equally be achieved even without SSPI if for example the NTLM_WB works as intended. Additionally not all capabilities of each libcurl flavour expose everything. Steve Holme steve_ho...@hotmail.com wrote: There are two reasons for including Windows SSPI in the version information. 1) curl displays the SSL library in its version string and as such should display something when SSL through Windows SSPI is enabled. Should? Why? What does it provide besides completeness? SSL support is indicated by 'https', 'ftps', etc in the supported protocols list, and that SSPI is in use in the features list. 2) Windows SSPI can be thought of as the equivalent to OpenSSL or better still GNUTLS as it is a provider of security related features and provides libcurl with the following: I still find no need to expose it in this new way which has been introduced. From discussion with Daniel, and to a certain degree from your email of 23 April, I believe that the feature of SSPI as listed in curl's feature string actually represents the SSO capability of Windows SSPI and not everything that Windows SSPI provides (or at least it shouldn't represent all of SSPI as otherwise you wouldn't display GSS-Negotiate and NTLM for example). Ah, forget that mail of mine, I wrote it out of memory. The fact is that SSPI feature actually represents that security.dll or secur32.dll is in use. Very long-long time ago it represented SSO but that was changed also long time ago to what it represents currently. WinSSPI is a short friendly name, or package name if you like, for security.dll / secur32.dll just as OpenSSL is the package name for libssl32.dll and libeay32.dll. Originally, Mark had this as SChannel which we decided wasn't a good name. I also find it a good name, but no need to use it. SSPI might use schannel.dll, ntlmssp.dll, kerberos.dll, cryptdll.dll and any other that gets properly injected into the system. Should we also show the version of those libs? The user/developer has very little choice relative to which version is used. This is very true... and I guess it would be similar to something like OpenSSL being pre-installed as part of Solaris for example ;-) Even on Solaris a user might build on its own a different OpenSSL version and use it, thing which is absolutely impossible on Windows for security.dll, secur32.dll and all MS system libs. So my question remains why do we need to expose MS system lib version? My own preference is to keep it because 1) It is in keeping with other security providers in curl, 2) Like any of the version / package information it is useful to know and 3) We need to display something in the SSL version string so if we were to ditch it what would we display here? Well, its clear we have different opinions on this. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
2012/6/12 Guenter li...@gknw.net well, perhaps a compromise would be if we just display SSL-Windows-native like we do with WinIDN ? That would drop the new dependency to the version lib while remaining the information that SSL is provided through a Windows system lib rather than through an expternal lib (same as with WinIDN). Here's an output of a build with WinIDN: curl 7.26.0 (x86_64-pc-win32) libcurl/7.26.0 OpenSSL/1.0.0j zlib/1.2.7 IDN-Windows-native libssh2/1.4.2 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN Largefile NTLM SSL SSPI libz I like this idea. That way Curl_schannel_version would still return something useful while avoiding the dependency on version.lib. +1 from me. Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Marc Hoersken i...@marc-hoersken.de wrote: I like this idea. That way Curl_schannel_version would still return something useful while avoiding the dependency on version.lib. Do you also mean that '-DWIN_USE_SSPI' also needs to drop the version.lib requirement? I mean, 'WIN_USE_SSPI' without 'USE_SCHANNEL'. I'm in favour of loading version.dll dynamically if we absolutely need version info. --gv --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi again, On Tue, 12 Jun 2012, Yang Tse wrote: Apologies if any of what I write sounds a little off or abrupt... it isn't my intention! I was tucked up in bed keeping warm as I'm really not feeling too good, I currently have a temperature yet am cold and am feeling sick at the same time, but I saw the email come in on my phone so I thought I should respond properly at the keyboard whilst things are still fresh in everyone's mind. There are two reasons for including Windows SSPI in the version information. 1) curl displays the SSL library in its version string and as such should display something when SSL through Windows SSPI is enabled. Should? Why? What does it provide besides completeness? If we don't put anything in here then what will a programmer who is using ssl_version from the result of curl_version_info() get? Surely we need to include something if CURL_VERSION_SSL is indicated in the features flags? SSL support is indicated by 'https', 'ftps', etc in the supported protocols list, and that SSPI is in use in the features list. 2) Windows SSPI can be thought of as the equivalent to OpenSSL or better still GNUTLS as it is a provider of security related features and provides libcurl with the following: I still find no need to expose it in this new way which has been introduced. Why? I'm not sure if I have missed something but can you please explain what you don't like about it? Is it the fact that Windows SSPI is listed in the version string, or that it uses the version number of secur32.dll for example, or that it uses version.lib to statically link with ? From discussion with Daniel, and to a certain degree from your email of 23 April, I believe that the feature of SSPI as listed in curl's feature string actually represents the SSO capability of Windows SSPI and not everything that Windows SSPI provides (or at least it shouldn't represent all of SSPI as otherwise you wouldn't display GSS-Negotiate and NTLM for example). Ah, forget that mail of mine, I wrote it out of memory. I'm sorry but how are Marc and I supposed to know that? This, if my memory serves me right, was the last thing your wrote on the forums about this. Since then we have asked for feedback about USE_WINDOWS_SSPI vs USE_WINDOWS_SSO as well as the version information but only received limited responses. SSL using Windows SSPI Schannel was something that Daniel wanted to see in the upcoming 7.27.0 release. Since then I have, possibly, wasted two Sunday's assisting Marc in trying to sort out the version information sorted as I was under the impression that this is something that needs to be present in ssl_version, and subsequently curl's version string, in help get the schannel additions into this release. The fact is that SSPI feature actually represents that security.dll or secur32.dll is in use. Very long-long time ago it represented SSO but that was changed also long time ago to what it represents currently. I do believe that SSPI shouldn't be listed in the features list as it currently is - as per the emails from last night. I have already documented a new section in docs\TODO to either replace / remove CURL_VERSION_SSPI from the next major version number but haven't pushed it in light of this discussion. As such I would like to see individual features such as SSO listed instead - as you also wrote that NTLM_WB does / could / should provide. WinSSPI is a short friendly name, or package name if you like, for security.dll / secur32.dll just as OpenSSL is the package name for libssl32.dll and libeay32.dll. Originally, Mark had this as SChannel which we decided wasn't a good name. I also find it a good name, but no need to use it. Again why not? SSPI might use schannel.dll, ntlmssp.dll, kerberos.dll, cryptdll.dll and any other that gets properly injected into the system. Should we also show the version of those libs? No not at all - and I think the fact that we have used the version information from secur32.dll is a bit of a hack to get a version number as I would prefer to call a function in SSPI to get the version number. Now please don't think I'm shifting the blame here, I'm not, but this was how Marc had written Curl_version_info() - I have tried to take that, clean it up a little and make it more general as to display the fact the Windows SSPI is in use as a provider of security features like as I have already said GNUTLS and other security providers are displayed by curl. Given the hack and after some digging around in system32... sspicli.dll would be a better library to use for the version information as like you say Windows SSPI might pull in other libraries. The user/developer has very little choice relative to which version is used. This is very true... and I guess it would be similar to something like OpenSSL being pre-installed as part of Solaris for example ;-) Even on Solaris a user might build on its own a different
Re: Windows SSPI Schannel implementation ready
Steve Holme steve_ho...@hotmail.com wrote: I was tucked up in bed keeping warm as I'm really not feeling too good, Get well soon. If we don't put anything in here then what will a programmer who is using ssl_version from the result of curl_version_info() get? Aha!, real reasons for us to chew on. Although man page claims it is only for OpenSSL... As Gün sugested SSL-Windows-native or WinSSL without version number information. But, only when actually using Windows SSL implementation. Unless I'm wrong, that is when schannel is in use not simply when SSPI is used. I still find no need to expose it in this new way which has been introduced. Why? I'm not sure if I have missed something but can you please explain what you don't like about it? Mostly library version number given for a system library. -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Steve, 2012/6/12 Steve Holme steve_ho...@hotmail.com: I was tucked up in bed keeping warm as I'm really not feeling too good, I currently have a temperature yet am cold and am feeling sick at the same time, but I saw the email come in on my phone so I thought I should respond properly at the keyboard whilst things are still fresh in everyone's mind. Get well soon, Steve. Thanks for still being around this time. Since then we have asked for feedback about USE_WINDOWS_SSPI vs USE_WINDOWS_SSO as well as the version information but only received limited responses. SSL using Windows SSPI Schannel was something that Daniel wanted to see in the upcoming 7.27.0 release. Since then I have, possibly, wasted two Sunday's assisting Marc in trying to sort out the version information sorted as I was under the impression that this is something that needs to be present in ssl_version, and subsequently curl's version string, in help get the schannel additions into this release. Thanks for your help here. I was also under the impression that this was something that should be done before the merge at that time. No not at all - and I think the fact that we have used the version information from secur32.dll is a bit of a hack to get a version number as I would prefer to call a function in SSPI to get the version number. Now please don't think I'm shifting the blame here, I'm not, but this was how Marc had written Curl_version_info() - I have tried to take that, clean it up a little and make it more general as to display the fact the Windows SSPI is in use as a provider of security features like as I have already said GNUTLS and other security providers are displayed by curl. It was me implementing Curl_schannel_version using version.lib after Gisle suggested the change, which sounded very reasonable to me at this point, because wVersion in SecPkgInfo was always 1. After I created the first version of this new approach, Steve did some cleanup and general refactoring. Given the hack and after some digging around in system32... sspicli.dll would be a better library to use for the version information as like you say Windows SSPI might pull in other libraries. I am not sure about this, since MSDN lists secur32.lib / secur32.dll as the host of the Schannel functions. For example: http://msdn.microsoft.com/en-us/library/windows/desktop/aa375348.aspx Generally speaking I am totally fine with whatever you people decide, as long as it is possible for the developer and user to tell if SSPI and/or SChannel is available/used. I don't think the version number is important, but the fact that it is available is. Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
On Mon, 11 Jun 2012, Marc Hoersken wrote: Therefore I am attaching a complete new set of patches that differs after 38984c2775651c8fb675528b20fa8d54ba43e2c6 (patch 0022). Sorry for the inconvenience. Please drop the old set and use the new one. Thanks for your hard work on this! I've merged this into a local branch of mine (with some manual fiddles due to the CRLF newlines in some files) and I've done some small local cleanups. A question I have is about the removal of CURL_VERSION_SSPI. What's the gain in removing this bit? We're set to keep the API backwards compatible so we better not remove the definition from the header file, but won't there also be one or a few applications existing that actually checks that bit to see if libcurl is built with SSPI? -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Daniel, 2012/6/11 Daniel Stenberg dan...@haxx.se: On Mon, 11 Jun 2012, Marc Hoersken wrote: Therefore I am attaching a complete new set of patches that differs after 38984c2775651c8fb675528b20fa8d54ba43e2c6 (patch 0022). Sorry for the inconvenience. Please drop the old set and use the new one. Thanks for your hard work on this! I've merged this into a local branch of mine (with some manual fiddles due to the CRLF newlines in some files) and I've done some small local cleanups. You're welcome! I had quite a lot of fun creating this. :-) Did you use the latest set of patch files? Actually that set shouldn't contain CRLF newline issues anymore. If it does, please tell me the location so that I can fix it on my branch and provide a new patch file. I am also very interested in the small local cleanups. ;-) I would to make sure that changes created due to misunderstandings or similiar make it into the master. A question I have is about the removal of CURL_VERSION_SSPI. What's the gain in removing this bit? We're set to keep the API backwards compatible so we better not remove the definition from the header file, but won't there also be one or a few applications existing that actually checks that bit to see if libcurl is built with SSPI? I didn't implement this change, but maybe Steve is able to elaborate a little bit on this part. Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
I would to make sure that changes created due to misunderstandings or similiar make it into the master. That sentence should read: I would like to make sure that changes created due to misunderstandings or similiar do not make it into the master. Sorry. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
On Mon, 11 Jun 2012, Marc Hoersken wrote: Did you use the latest set of patch files? Actually that set shouldn't contain CRLF newline issues anymore. If it does, please tell me the location so that I can fix it on my branch and provide a new patch file. The CRLFs are in the windows makefiles, I would expect them to be there! ;-) I am also very interested in the small local cleanups. ;-) Yes sure, but I was thinking I would just clear up this CURL_VERSION_SSPI thing first and then I would push this to the master branch to let everyone play with it and then we could work on further work/patches from there. That's why I haven't made my small fixes public yet as I think they will be very soon anyway. A question I have is about the removal of CURL_VERSION_SSPI. What's the gain in removing this bit? We're set to keep the API backwards compatible so we better not remove the definition from the header file, but won't there also be one or a few applications existing that actually checks that bit to see if libcurl is built with SSPI? I didn't implement this change, but maybe Steve is able to elaborate a little bit on this part. Oh I missed that. So Steve, any comments? -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi Daniel, On Mon, 11 Jun 2012, Daniel Stenberg wrote: A question I have is about the removal of CURL_VERSION_SSPI. What's the gain in removing this bit? We're set to keep the API backwards compatible so we better not remove the definition from the header file, but won't there also be one or a few applications existing that actually checks that bit to see if libcurl is built with SSPI? That was my doing... The rational for that was: We had discussed that SSPI was a library / provider of security features such a Security Contexts (GSS-Nego, NTLM, etc...) and now SSL and as such should not appear on the features list in the same way that OpenSSL or GNUTLS don't. Removing CURL_VERSION_SSPI from the features array (in src\tool_getparam.c) and the features part of the version struct (lib\version.c) then left the only reference in curl.h As such I then obsoleted the #define and commented it as such rather than removing it completely. Do we need to keep this in for API compatibility? NTLM, GSS-Negotiate and SSL tell the developer the features that the Windows SSPI library provides. Kind Regards Steve --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Daniel, 2012/6/11 Daniel Stenberg dan...@haxx.se: On Mon, 11 Jun 2012, Marc Hoersken wrote: Did you use the latest set of patch files? Actually that set shouldn't contain CRLF newline issues anymore. If it does, please tell me the location so that I can fix it on my branch and provide a new patch file. The CRLFs are in the windows makefiles, I would expect them to be there! ;-) Yes, I noticed that Makefile.vc has UNIX line endings and MakefileBuild.vc has DOS line endings. Maybe those two files and the Windows .bat files can all be changed to Windows line endings after the merge? Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi again, Oh I missed that. So Steve, any comments? I just replied a minute or so ago... whilst Outlook was grabbing the latest messages from Hotmail ;-) S. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
2012/6/11 Marc Hoersken i...@marc-hoersken.de: Hi Daniel, 2012/6/11 Daniel Stenberg dan...@haxx.se: On Mon, 11 Jun 2012, Marc Hoersken wrote: Did you use the latest set of patch files? Actually that set shouldn't contain CRLF newline issues anymore. If it does, please tell me the location so that I can fix it on my branch and provide a new patch file. The CRLFs are in the windows makefiles, I would expect them to be there! ;-) Yes, I noticed that Makefile.vc has UNIX line endings and MakefileBuild.vc has DOS line endings. And again a mistake on my end.. this is not my day. Makefile.vc already has DOS-style line endings. MakefileBuild.vc has UNIX-style line endings. BUILD.WINDOWS.txt and gen_resp_file.bat are also correctly using DOS-style line endings. Best regards Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
On Mon, 11 Jun 2012, Steve Holme wrote: We had discussed that SSPI was a library / provider of security features such a Security Contexts (GSS-Nego, NTLM, etc...) and now SSL and as such should not appear on the features list in the same way that OpenSSL or GNUTLS don't. I agree with this, generally. However in this case... Do we need to keep this in for API compatibility? NTLM, GSS-Negotiate and SSL tell the developer the features that the Windows SSPI library provides. Yes. We need to make existing libcurl-using source code keep compilign so we need the define to remain in the header file. We also probably need to provide the bit in the struct so that the ABI remain the same for existing code. We added SSPI in the curl output and as a feature bit once upon the time partly because libcurl built with SSPI provides certain features that libcurl without SSPI doesn't possess (I'm thinking of the ability to magically use the logged in user's username + password) so a user might in fact want to figure out if that ability exists or not. I hope none of you mind very much that I intend to bring it back again? -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Daniel, 2012/6/11 Daniel Stenberg dan...@haxx.se: On Mon, 11 Jun 2012, Steve Holme wrote: We had discussed that SSPI was a library / provider of security features such a Security Contexts (GSS-Nego, NTLM, etc...) and now SSL and as such should not appear on the features list in the same way that OpenSSL or GNUTLS don't. I agree with this, generally. However in this case... Do we need to keep this in for API compatibility? NTLM, GSS-Negotiate and SSL tell the developer the features that the Windows SSPI library provides. Yes. We need to make existing libcurl-using source code keep compilign so we need the define to remain in the header file. We also probably need to provide the bit in the struct so that the ABI remain the same for existing code. We added SSPI in the curl output and as a feature bit once upon the time partly because libcurl built with SSPI provides certain features that libcurl without SSPI doesn't possess (I'm thinking of the ability to magically use the logged in user's username + password) so a user might in fact want to figure out if that ability exists or not. I hope none of you mind very much that I intend to bring it back again? No problem for me. I think the best approach would be to bring it back to keep the ABI compatiblity while still having the new version information output. Do you have anything else you want to discuss before merging the Schannel branch, Daniel? :-) Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi Daniel, On Mon, 11 Jun 2012, Daniel Stenberg wrote: We added SSPI in the curl output and as a feature bit once upon the time partly because libcurl built with SSPI provides certain features that libcurl without SSPI doesn't possess (I'm thinking of the ability to magically use the logged in user's username + password) so a user might in fact want to figure out if that ability exists or not. Just out of interest - does that feature still exist and work? How does an end Windows user tell curl to use the currently logged in user? I hope none of you mind very much that I intend to bring it back again? The purist in me likes to tidy things up and keep things clean - however, I do understand that APIs need to be kept. Do we need to keep both API and ABI compatibility? S. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
On Mon, 11 Jun 2012, Marc Hoersken wrote: Do you have anything else you want to discuss before merging the Schannel branch, Daniel? :-) Nope. Merged and pushed just now. Go and try it out! -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
On Mon, 11 Jun 2012, Steve Holme wrote: We added SSPI in the curl output and as a feature bit once upon the time partly because libcurl built with SSPI provides certain features that libcurl without SSPI doesn't possess (I'm thinking of the ability to magically use the logged in user's username + password) so a user might in fact want to figure out if that ability exists or not. Just out of interest - does that feature still exist and work? How does an end Windows user tell curl to use the currently logged in user? IIRC you just use : as name/password, but I don't know if it still works as unfortunately we don't test that in the test suite since that doesn't run on Windows... :-/ Do we need to keep both API and ABI compatibility? Yes. As much as posssible! -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi again, Just out of interest - does that feature still exist and work? How does an end Windows user tell curl to use the currently logged in user? IIRC you just use : as name/password, but I don't know if it still works as unfortunately we don't test that in the test suite since that doesn't run on Windows... :-/ It seems to work for both smtp and pop3 - if I've tested it correctly! ;-) curld -v -k --url pop3://mail --user : Gave me: +OK User successfully logged on. LIST +OK 32 36794182 1 4299 2 1915222 3 1132096 ... Do we need to keep both API and ABI compatibility? Yes. As much as posssible! No problem - perhaps something we can add to clean up list for a major update. Alternatively, as see SSPI is back on the features list as well... First was that your intention? Secondly, if so would that string be better off as SSO for Single Sign On so GSS-Nego, NTLM, SSL and SSO are features of SSPI ? Cheers Steve --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
On Mon, 11 Jun 2012, Steve Holme wrote: No problem - perhaps something we can add to clean up list for a major update. Yes, there's a list of such stuff at the bottom of the TODO (section 18 and 19). Alternatively, as see SSPI is back on the features list as well... Yes, only to keep the option there in case thhere's a user using it. Secondly, if so would that string be better off as SSO for Single Sign On so GSS-Nego, NTLM, SSL and SSO are features of SSPI ? Nah, I thought basically for backwards compatibility so even if we think SSO is a better name we still need SSPI in there for old time's sake... -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Daniel, 2012/6/11 Daniel Stenberg dan...@haxx.se: On Mon, 11 Jun 2012, Marc Hoersken wrote: Do you have anything else you want to discuss before merging the Schannel branch, Daniel? :-) Nope. Merged and pushed just now. Go and try it out! Great! Thank you very much. The merge looks great. Just out of curiosity: What is the maximum line length for code lines? The lines you shortened were 80 character long, which I thought was correct. I also saw, why you thought that I did the SSPI version changes. It looks like me fixing the whitespace issues, in the patches provided to me by Steve, made curl put my name into the commits during amending. Best regards, Marc --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: Windows SSPI Schannel implementation ready
Hi Marc, Nope. Merged and pushed just now. Go and try it out! Great! Thank you very much. The merge looks great. It's great we got this into 7.27.0 ;-) Just out of curiosity: What is the maximum line length for code lines? The lines you shortened were 80 character long, which I thought was correct. The definition in checksrc.pl is 79 but I always using column 79 as my cut off in Visual Studio (so my lines always end up being 78 characters long). S. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
On Tue, 12 Jun 2012, Marc Hoersken wrote: Just out of curiosity: What is the maximum line length for code lines? The lines you shortened were 80 character long, which I thought was correct. The lib/checksrc.pl script warns on 79 columns - and the script runs automatically on configure --enable-debug builds which is what I usually use. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Marc, Am 10.06.2012 22:54, schrieb Marc Hoersken: with the support of Steve and Guenter, I was able to ready my Windows SSPI Schannel implementation. naa, not worth to mention me at all - I did contribute nothing but few small commits! Great work, Marc! And thanks to Steve too who did also put a bunch of energy into it. Gün. (if you're looking for something new to attack then take a look at libssh2 - perhaps its possible to provide the crypto stuff there too from Schannel; that would be very great since it would remove the dependecy to either openssl or libgcrypt ...) --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hello again, sorry, but I have to submit two more patches for the mingw32 build: - sspi: Fixed incompatible parameter pointer type in Curl_sspi_version - mingw32: Fixed warning of USE_SSL being redefined And just for the record, the following things are left to be done for the Schannel implementation: - implement write buffering - implement SSL/TLS shutdown - implement client certificate authentication - implement custom server certificate validation - implement cipher/algorithm option Best regards, Marc 2012/6/10 Marc Hoersken i...@marc-hoersken.de: Hello everyone, with the support of Steve and Guenter, I was able to ready my Windows SSPI Schannel implementation. Attached you will find a zip-file containing separate patch files for each commit. The other file attached is a whole patch file containing the commit history. I squashed the commit history and removed obsolete commits in order to have a clean history. I also updated the RELEASE-NOTES and FEATURES docs as well as adding myself to the THANKS list: https://github.com/mback2k/curl/commit/e439268e3aee707a816b313d7fe7f06be364505f The corresponding branch can be found here: https://github.com/mback2k/curl/tree/schannel-ready A comparision between the current master and this branch can be found here: https://github.com/mback2k/curl/compare/schannel-ready The patche(s) should easily apply to the current master 72c7c1d64e: https://github.com/bagder/curl/commit/72c7c1d64e101675520387c0d758b63f71d4c48a It would be great if everyone could help do a little final build testing before this is merged. We need tests using mingw32 cross-compilation, native-compilation and the VC winbuild scripts. I would appreciate any help on this matter, thanks in advance! Best regards, Marc 0027-sspi-Fixed-incompatible-parameter-pointer-type-in-Cu.patch Description: Binary data 0028-mingw32-Fixed-warning-of-USE_SSL-being-redefined.patch Description: Binary data --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hello again, shame on me, but I have to submit another small patch with just a single character being added: - Fixed missing pointer cast in Curl_sspi_version Best regards, Marc 0029-sspi-Fixed-missing-pointer-cast-in-Curl_sspi_version.patch Description: Binary data --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Windows SSPI Schannel implementation ready
Hi Marc, I'll look soonish into all this. An ultra fast patch skimming shows there are line ending problems (changed from UNIX to DOS) in at least all lines of include/curl/curl.h and lib/setup.h -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
