cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: after 7.26.0

From: Marc Hoersken <info_at_marc-hoersken.de>
Date: Sun, 10 Jun 2012 14:10:30 +0200

Hi Steve,

2012/6/10 Steve Holme <steve_holme_at_hotmail.com>
>
> Hi Marc,
>
> > > * Cloned the repository from https://github.com/mback2k/curl.git
> > > * Switched to the schannel-rebase-00fddba672 branch
> >
> > That's a way to do it. But if you want to push to your own repo instead
> > of needing to generate e-mail patches, you could have created a fork on
> >  github.com. Anyway, you can just send your commits as a patch to the
> > mailinglist.
>
> Oooo, Forking sounds a bit scary - I think I'll stick with the email patches ;-)

Oh, it's absolutely not. Did you take a look at the guide on github.com?
https://help.github.com/articles/fork-a-repo

>
>
> > > Will I have direct commit / push access to that branch or should I be
> > > working differently?
> >
> > Yes, you will have commit access to your local clone, but you won't be
> > able to push to my personal fork on github.com.
>
> No problem - I wasn't sure whether you wanted the changes as patches or whether you wanted to give me access to your fork.

I cannot give you direct write access to my fork. For that I would
have to add your private SSK key to my github.com account.
First of all it is not possible to add the same key to different
accounts, so you would have to generate a separate key.
Second of all you would have access to all my personal repositories. I
am sorry, but that's not an option. ;-)

> > A better approach would to fork Daniel's repo and then pull my
> > changes into it.
>
> Now that's starting to sound really scary ;-)
>
> > > I've just added support for APOP in a local branch here, which I hope
> > > to push over the weekend and once that is out of the way / whilst I
> > > wait for the autobuilds to run I will hopefully be able to re do my
> > > version info changes into your branch.
> >
> > Cool!
>
> Just to give you an update...
>
> * I pushed all my changes to the main curl repo in order to add support for APOP
> * I have updated your repo and branch schannel-rebase-00fddba672 with my version changes here
> * I have tested the following configurations to make sure --version displays the correct information:
>
>    1) No SSPI
>    2) No SSPI and OpenSSL
>    3) SSPI but no SSL
>    4) SSPI with OpenSSL
>    5) SSPI with SChannel SSL
>
> * The results were:
>
> 1) curl 7.27.0-DEV (x86_64-pc-win32) libcurl/7.27.0-DEV                         Features: AsynchDNS Largefile
> 2) curl 7.27.0-DEV (x86_64-pc-win32) libcurl/7.27.0-DEV OpenSSL/1.0.0e          Features: AsynchDNS Largefile NTLM SSL
> 3) curl 7.27.0-DEV (x86_64-pc-win32) libcurl/7.27.0-DEV sspi/6.1.7601                   Features: AsynchDNS GSS-Negotiate Largefile NTLM
> 4) curl 7.27.0-DEV (x86_64-pc-win32) libcurl/7.27.0-DEV OpenSSL/1.0.0e sspi/6.1.7601    Features: AsynchDNS GSS-Negotiate Largefile NTLM SSL
> 5) curl 7.27.0-DEV (x86_64-pc-win32) libcurl/7.27.0-DEV sspi/6.1.7601                   Features: AsynchDNS GSS-Negotiate Largefile NTLM SSL

That looks great! Thanks for your work on this.

> I now need to:
>
> * Separate the work into two patches and email them to you
>
> Just a quick question before I do that though... Should we have the version string as "sspi" as I have done or as "WinSSPI" ?

I would be like to see it show up as either "SSPI" or "WinSSPI", as
it's an uppercase abbreviation. Just my 2 cent.

>
> I appreciate this maybe still to do... but a little bit of feedback as I found having to add USE_WINDOWS_SSPI; USE_SSL; USE_SCHANNEL to the pre-processor section of my Visual Studio project a little confusing to enable SSPI and SChannel based SSL.
>
> I thought that by having USE_SCHANNEL that would automatically define USE_SSL.

So in the end you mean that USE_SSL should automatically be defined if
USE_SCHANNEL is defined?

Best regards,
Marc

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-06-10