On Sat, Nov 09, 2013 at 10:21:19AM -0800, Richard Levenberg wrote:
> I run a service and have developed modules for Drupal and Wordpress
> that integrate with the service. In order to connect to the service,
> client-authenticated SSL is required. The service is a walled garden;
> it uses none of the standard CA certificates for
> verification. Recently relevant information is that the PKI
> infrastructure I have set up uses keys larger than 4096 bits.
>
> A very large customer of mine tried to install the Drupal module on
> the standard Amazon Linux AMI and the module did not work. After a lot
> of scrambling, I figured out that the RedHat based curl is compiled
> against NSS rather than OpenSSL. With the recent update to OS X
> Maverics (10.9), the curl is compiled against SecureTransport.
>
> The specific problems with these changes is that there are no PHP
> bindings to NSS or SecureTransport so I can't programmatically do
> anything. I also can't install any >4096 bit keys or signatures into
> SecureTransport so I can't manually do anything either.

You're complaining in the wrong place if this is the issue. The curl
project has nothing to do with the PHP/CURL binding. If the issue is
lack of support in PHP for some libcurl features, then you should
contact the people responsible for the PHP binding.

> While I personally can suffer doing manual operations to get curl
> working (using certutil and friends) I am hesitant to ask customers
> that want to use my service to do these things. And for my purposes,
> Mac OS X has either become a non-functional development environment or
> I'm faced with compiling OpenSSL and curl everytime I upgrade.
>
> Going forward, I would like for the semantics of the curl options to
> NOT mean different things on different OS's. I'm non-plussed at the
> comment "think that's it. Other than --cacert I doubt these changes
> will affect anyone" from
> http://curl.haxx.se/mail/archive-2013-10/0036.html
>
> What that says to me is that the curl development is either unaware of
> my use case or doesn't care. Neither is particularly helping with my
> frustration. I think a better way to have handled this is to provide
> the option to use OS specific implementations (NSS or SecureTransport)
> and have the distributions SET that option. That way that option can
> be UNSET and the regular CLI works semantically correct on every OS.

Another possibility that you haven't mentioned is that libcurl supports
features that are only supported by some of the low-level SSL libraries that
can be used with libcurl. This is actually the case, and the alternative of
dumbing down libcurl to only support the lowest common denominator isn't
very attractive.

If your application requires features that are not supported by all possible
SSL libraries in use by libcurl, then you need to document which one your
system, or your customer service department, supports. Or, supply your own
binary using a known-working configuration.

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-11-09