-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
configure does not validate --with-ca-path and/or --with-ca-bundle #404
Comments
And here's the result when using an absolute path for
And nothing set in the environment:
Using just 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 |
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.
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
But OpenSSL expects the 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:
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." |
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...
I'm familiar with OpenSSL. But If |
alright here's draft 1
if the path is not found you should see this when configure completes:
I'll have to add parentheses around the warning Anyone familiar with autoconf want to give it a look? I rarely do it so I'm not sure if all the syntax and logic is ok. as far as the sslcerts page goes I don't know what to put there if anything. yes it doesn't discuss the configure options, but should it. also i said 'full path' in my last post i don't know why i wrote that. it takes a path, not necessarily a full path. |
I don't think there's a strict requirement to have an absolute path there, although of course it seems nuts to not use one for most users. |
Looks good to me! |
@jay, you intend to merge that or are there any second thoughts? |
I'm pretty sure I intended to test it more but I forgot. I'll take a look soon. |
- Warn if --with-ca-bundle file does not exist. - Warn if --with-ca-path directory does not contain certificates. - Improve help messages for both. Example configure output: ca cert bundle: /some/file (warning: certs not found) ca cert path: /some/dir (warning: certs not found) Bug: #404 Reported-by: Jeffrey Walton
@noloader Thank you for your suggestion. I have updated the help text and also added a warning. The changes landed in 3ae77f0. Help looks like this:
Warning looks like this:
|
looks like someone needs to have their account suspended from GitHub. |
A configuration with the following:
Configures fine. At runtime, it produces an error:
cURL has access to both the path and the file:
According to
configure --help
, I've set them as I'm supposed to. I provided the path via--with-ca-path
, and I provided the filename via--with-ca-bundle
There seems to be a lot of trouble with these options and lack of validation. Here's the number one search result: http://curl.haxx.se/mail/curlphp-2005-11/0038.html. In this report, the permissions were wrong. Configure could have easily tested it, but it did not.
Here's the number two search result: https://stackoverflow.com/questions/3160909/how-do-i-deal-with-certificates-using-curl-while-trying-to-access-an-https-url. The advice is to read the primary reference at http://curl.haxx.se/docs/sslcerts.html.
Unfortunately, the primary reference language is ambiguous and it lacks a working example. For example, when you say "FILE", do you mean just the filename (
curl-ca-bundle.crt
), or do you mean the fully qualified or absolute filename (/usr/share/curl/curl-ca-bundle.crt
)?It would be very helpful to users to state _exactly_ and _precisely_ what cURL expects or needs. It would also be very helpful to users if
configure
validated the--with-ca-path
and--with-ca-bundle
.The text was updated successfully, but these errors were encountered: