[Networking] Search for CA roots if libcurl doesn't know where they are. #4877
Conversation
Normally, distro maintainers will tell libcurl where to look when they build it, and up to now we've been relying on that. That doesn't work for the fully static Linux build, where we're building our own libcurl, and where the idea is that we'll run on any old Linux system. To make TLS work under that circumstance, we'll need to look in a few likely places for CA root files. We only do this if libcurl doesn't already know where to look. rdar://123434144
|
@swift-ci Please test |
|
Looks like older curl might not define Update: according to the curl repo, we need curl 7.84.0 to get |
|
Not sure what that macOS failure is about. Seems we're generating references to |
`curl` versions before 7.84.0 don't have `CURLINFO_CAINFO`, so we can't tell whether they've got an existing path for the CA roots in that case. We should disable the automatic search in that case, because it would override the baked-in default. rdar://123434144
|
@swift-ci Please test |
|
@swift-ci test windows |
|
@swift-ci test macos |
This code isn't used on macOS. :-) (I realised after my comment last week, and after noticing that only Linux and Windows were required.) |
|
I understand, I would like to see if macOS is still failing for all PRs or only a specific one. |
| // be set, so leave things alone | ||
| var p: UnsafeMutablePointer<Int8>? = nil | ||
|
|
||
| try! CFURLSession_easy_getinfo_charp(rawHandle, CFURLSessionInfoCAINFO, &p).asError() |
There was a problem hiding this comment.
Have we tested with curl < 7.84.0 to make sure the NS_CURL_MISSING_CURLINFO_CAINFO properly guards this code? I think it should, but I'd just want to make sure, otherwise I think this will always fatalError since curl will return CURLE_UNKNOWN_OPTION. It might be good to just catch the error here and return instead of force trying.
There was a problem hiding this comment.
Yes. The original version of this PR actually failed because of this problem, so the guard definitely works.
| "/etc/pki/tls/certs/ca-bundle.crt", | ||
| "/usr/share/ssl/certs/ca-bundle.crt", | ||
| "/usr/local/share/certs/ca-root-nss.crt", | ||
| "/etc/ssl/cert.pem" |
There was a problem hiding this comment.
Out of curiosity, is there reasoning or precedence for this search order? (I don't see any issue with it, I'm just not as familiar.)
There was a problem hiding this comment.
I took the list from curl's build system (I assumed that was a good place to look, because it already knows how to do this, just during configuration rather than at runtime).
| isDirectory: &isDirectory) | ||
| && !isDirectory.boolValue { | ||
| path.withCString { pathPtr in | ||
| try! CFURLSession_easy_setopt_ptr(rawHandle, CFURLSessionOptionCAINFO, UnsafeMutablePointer(mutating: pathPtr)).asError() |
There was a problem hiding this comment.
Same idea as above making sure with don't get CURLE_UNKNOWN_OPTION.
There was a problem hiding this comment.
Again, the we failed in one of the previous iterations because of this, so yes, it's been tested.
[Networking] Search for CA roots if libcurl doesn't know where they are.
Normally, distro maintainers will tell libcurl where to look when they build it, and up to now we've been relying on that. That doesn't work for the fully static Linux build, where we're building our own libcurl, and where the idea is that we'll run on any old Linux system.
To make TLS work under that circumstance, we'll need to look in a few likely places for CA root files. We only do this if libcurl doesn't already know where to look.
rdar://123434144