And here's the result when using an absolute path for --with-ca-bundle, and _not_ using --with-ca-path:

$ ./src/.libs/curl https://www.google.com -o index.html
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current   Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (77) error setting certificate verify locations:
  CAfile: curl-ca-bundle.crt
  CApath: /usr/share/curl

And nothing set in the environment:

 $ printenv | grep -i curl
 PWD=/Users/<user>/curl-7.44.0

Using just --with-ca-path and _not_ using --with-ca-bundle produces the same result.

I have no idea why configure can't actually configure the library as specified, and where some of this stuff is coming from.

It validates that the given file is a file. It validates that the given directory is a directory. Why are you passing configure a path you don't want it to use?

We could possibly add a check for a "-----BEGIN CERTIFICATE-----" line, but I really don't think this is a source for as much trouble as you're claiming. Most people don't build their own curl with configure and for those who do, the default path detection works for most of them.

Then you mix in another matter, namely the sslcerts document. It speaks of file as in you specify the file name. That can be relative or absolute, just like how you specify file name to any application in your system.

From the point of release engineering I'd say, accept what is provided to configure and don't validate the paths or files then and there. I could be compiling curl on a machine completely different from the target environment.

Good point. I see no reason to change our current behavior.

It sounds like you guys are effectively saying, cURL had been downloaded hundreds of thousands or millions of time; and most of those times its so someone can build on one machine and install on another machine. I'd say that's pretty tenuous.

Based on decades of problems with it, I'd say maybe its time to rethink it. Or at least clean up the documentation so its clear and concise.

@noloader, what is the problem with giving configure the correct path? Why is this such a problem? And no, even if the majority doesn't build on one machine to pass it on to another, it is a use case that we support and that is not unreasonable so why not support it?

The vast majority of users who run configure will of course not even use those options as it is fairly good at detecting the system's default paths by itself.

Based on decades of problems with it,

You spent a decade trying to give it the correct CA path?

@badger - "what is the problem with giving configure the correct path..." - nothing. I gave it an existing path and an existing file name. It resulted in a runtime error.

so how is that configure's fault?

@badger - its a problem with the library. Since its a configuration option, I'm guessing its something configure can detect.

It looks like @noloader thought he could pass the certificate bundle's filename in --with-ca-bundle and the path to that certificate bundle in --with-ca-path.

curl: (77) error setting certificate verify locations:
CAfile: curl-ca-bundle.crt
CApath: /usr/share/curl

  --with-ca-bundle=FILE   File name to use as CA bundle
  --without-ca-bundle     Don't use a default CA bundle
  --with-ca-path=DIRECTORY
                          Directory to use as CA path
  --without-ca-path       Don't use a default CA path

But OpenSSL expects the full path to the certificate bundle in CAfile and uses CApath to look up CA certificates stored individually, each in a filename that is the hash of the subject name [1].

If someone is unfamiliar with OpenSSL that is a mistake they could make. So I think he has a point. What if we change it to something like this:

  --with-ca-bundle=FILE   Path to a filename that is a certificate bundle.
                          Example: /etc/ca-bundle.crt
  --without-ca-bundle     Don't use a default CA bundle
  --with-ca-path=DIRECTORY
                          Path to a directory containing CA certificates stored
                          individually. Refer to OpenSSL for the format.
                          Example: /etc/ca-certificates
  --without-ca-path       Don't use a default CA path

I don't have much of an opinion on more safety checks except I don't think they should cause an error. At the most I'd +1 a warning after configure completes like "WARNING: The certificate bundle was not found at the specified location."

I don't have much of an opinion on more safety checks except I don't think they should cause an error. At the most I'd +1 a warning

We could do a warning (and yeah we cannot do an error due to said cross-compiling or "build-here and run-there" setups). Assuming the check works properly independently of TLS backend in use.

The problem with configure warnings is probably that they scroll down fast and are easy to miss.

One quick comment...

If someone is unfamiliar with OpenSSL that is a mistake they could make....

I'm familiar with OpenSSL. But configure and http://curl.haxx.se/docs/sslcerts.html. don't state cURL wants the c_hash gear. When I RTFM, I try to perform literal reads, and I try to avoid guesses or leaps.

If PATH is a path to the c_hash gear, then state it. And you should also state you want an absolute path for FILE (--with-ca-bundle=FILE), and not a relative one.