On Jun 25, 2012, at 4:07 AM, Daniel Stenberg wrote:

> On Sun, 24 Jun 2012, Nick Zitzmann wrote:
>
>> I couldn't let Windows users have all the fun with the next major release of Curl, so yesterday I added preliminary support for SecureTransport.
>
> Lovely!
>
> Some initial comments:
>
> o I had to remove the C++/c99 comment from lib/securetransport.h to be able
> to build since I use -Werror and enforce c89…

Ah, sorry. I left that in while testing something. I'll un-stage and fix that, along with the other comments.

> o please use memset() instead of bzero() for consistency

Sure.

> o regarding the ioErr = -36, doesn't that value have a name in the header that
> you can include in the comment to help a reader understand it? Also, I would
> prefer a #define to a static const…

ioErr is defined in MacErrors.h, which is part of the Carbon framework, which means it has been around since 1984 I think. The problem is, that header is not present in iOS, which purges most (but not all) of Carbon. So I'll change it to a #define.

[…]
> This last command will fire up the environment correctly and use gdb to invoke the correct command. You'd then start with setting your break-points or whatever and then enter 'run' and watch the test case run.

Thanks for the instructions.

>> 2. Would anyone mind if I added a new selector to the curl_easy_getinfo() function that returns an OS-specific data structure? I ask because, if the trust fails, it's customary on Mac OS X for the app to present a certificate error window to the user showing the problem and asking if the user wants to proceed or cancel the connection . To do that, Curl needs to be able to share the underlying trust data structure (which is called "SecTrustRef") with the rest of the app. I thought about using CURLINFO_CERTINFO, which is the OpenSSL equivalent, but since the return type is totally different, that'll break every app that expected a curl_certinfo list in return.
>
> I might be OK with that if there truly is no other way. But is this really an OSX specific thing? A failed certificate check happens on all platforms for example when self-signed certs are used or similar.

The SecureTransport API evaluates the trust by getting the certificate chain from the server, creating a SecTrustRef data structure using that chain, and then calls a function that evaluates the trust. If it doesn't trust the chain for whatever reason (expired certificate, self-signed certificate, etc.) then it returns an error during the handshake.

Here in the real world, people use self-signed certificates all the time for intranet servers and other non-public things. And Mac OS X comes with a class called "SFCertificateTrustPanel" that can be used after a trust evaluation failed, and will show the failed SecTrustRef and what went wrong, so an app can display the failed trust to the user and ask the user how they want to proceed. Apple Mail, Safari, etc. already do this when connecting to an SSL server with a questionable chain. Third-party apps are going to want to do this as well. But to do this, we need to be able to share the SecTrustRef with the rest of the app.

Nick Zitzmann
<http://www.chronosnet.com/>

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