Handle CA certificate store better

[asherkin]

See #8, and this came up in IRC today.

I think the best behaviour here would be for RIP to compile with CURL_CA_BUNDLE undefined on all platforms, then implement its own search path logic and set CURLOPT_CAINFO appropriately at run time.

The current hardcoded path is incorrect on RHEL-based Linuxes, and doesn't handle the OS store being completely inaccessible because SRCDS is chrooted.

I think a reasonable set of search paths to start with would be:

1. BuildPath(Path_SM, "configs/cacert.pem") (So that people can drop in their own.)
2. /etc/ssl/certs/ca-certificates.crt (The current value, from wherever you built the config.)
3. /etc/ssl/certs/ca-bundle.crt (The RHEL / CentOS / Fedora default.)

RIP should take the first one that exists and is readable.

[ErikMinekus]

Thanks, I have been thinking about how to handle this. Reading through cURL's configure it seems to check these paths for the CA bundle:

/etc/ssl/certs/ca-certificates.crt Debian systems
/etc/pki/tls/certs/ca-bundle.crt Redhat and Mandriva
/usr/share/ssl/certs/ca-bundle.crt old(er) Redhat
/usr/local/share/certs/ca-root-nss.crt FreeBSD
/etc/ssl/cert.pem OpenBSD, FreeBSD (symlink)

So I could check these paths at runtime, or just include my own CA bundle in the package.

[asherkin]

Just a thought, but maybe SM could ship the CA bundle in the future?

If you think shipping one with RIP (for now) is reasonable, I think that makes sense.

How about:

1. BuildPath(Path_SM, "configs/cacert.pem") < for users to overload without risking overwrites
2. BuildPath(Path_SM, "data/cacert.pem") < ship this one with RIP / SM

EDIT: Actually, it looks like we ship the geoip database in configs anyway, so maybe just set it to that path :P

[ErikMinekus]

That would be great, you could even create a fresh CA bundle on every build with mk-ca-bundle.pl.

Love the paths, although I would probably put it in configs/ripext/ and data/ripext/ to avoid conflicts.

[ErikMinekus]

5886a45 should do the trick for now!