Certificate Authorities: curl-ca-bundle, certsync, keychain

[Rainer Müller]

Hey Landon,

On 2013-05-14 03:39, Landon Fuller wrote:
> Over the weekend I whipped up (and added a port for) 'certsync'; it's a small tool that fetches all trusted certificates from the Mac OS X system keychain, and then spits them out as OpenSSL-readable pem-encode certificate bundle.
> 
> The goal was to provide a replacement for curl-ca-bundle with the following benefits:
> 	- Uses the CAs Apple provides -- that way MacPorts doesn't have to be in the business of distributing CA certificates.
> 	- Also includes any custom CAs that the user has added. This is the case for many people who use internal CAs to sign certificates for their corporate (or personal) services.
> 	- Automatically updates (if the launchd item is loaded) when the System Keychain(s) or trust settings are modified. 

Thank you for your work! This really should make it easier to manage
certficates by unifying the previous distinct locations.

> There are a few gotchas that I could use input on, however:
> 	- curl-ca-bundle currently lays claim to ${prefix}/etc/openssl/cacerts.pem. This conflicts with certsync, and there's no way to have both installed at the same time.
> 	- A small number of ports directly depend on curl-ca-bundle to ensure that valid CA certificates are available.

I ran into this problem with the recent mercurial upgrade. I guess we
should rewrite this dependency such that it's satisfied by both ports:

depends_run	path:share/curl/curl-ca-bundle.crt:curl-ca-bundle

> 	- certsync can only keep the cert.pem file up-to-date if the launchd item is enabled. Ideally that would be done by default, but that's not currently supported.

Right, but we should have a note in certsync recommending to load the
launchd item.

Actually, there is already something printed when installing a port with
a startup item, but it's not a note so not repeated on activate.
I am not sure whether we already have a bug tracking that.

Rainer