Load certificates from systems keychain on darwin #8844
Conversation
The systems root keychain contains well know root certificates, yet is non-modifiable. As such, internal CA certificates (both root and intermediate) tend to get installed into the systems keychain in the context of an private organization. Not loading certs from this keychain results in differing behavior from other tools (e.g., openssl, curl, etc.). This commit changes to that so that ssl in conjunction with public key just works in such environments.
CT Test Results 2 files 17 suites 5m 15s ⏱️ Results for commit dcc396a. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
|
Note that a test in the appropriate test suite has not been added, I wasn't sure how that would play out since an import call would be needed a may require a password. To manually test this one simply needs to install a certificate into the systems keychain, startup erl, then verify the presence of the installed cert via |
Confirmed, this can not be easily tested in a suite. |
| case get_darwin_certs(SystemKeyChainFile) of | ||
| {ok, Bin2} -> | ||
| decode_result(<<Bin1/binary, Bin2/binary>>); | ||
| Err -> |
There was a problem hiding this comment.
Can this fail?
And if so should we just decode the SystemRoot bin which we already got and return that part which was successful?
There was a problem hiding this comment.
I thought about this, the system keychain is available to all users, so if it did fail, your system has serious problems :) That said, if we wanted to proceed anyway, we could log an error and proceed, wdyt?
There was a problem hiding this comment.
I thought that better safe than sorry, that will keep backward compatibility and since we can't test it, it might be a good idea. And I don't know anything MacOS so I don't know if it always is available on all versions.
There was a problem hiding this comment.
It's a solid point, I also want to take a stab at testing this on GH, the runner may act differently than my laptop 😄 No reason to rush this.
The systems root keychain contains well know root certificates, yet is non-modifiable. As such, internal CA certificates (both root and intermediate) tend to get installed into the systems keychain in the context of an private organization. Not loading certs from this keychain results in differing behavior from other tools (e.g., openssl, curl, etc.). This commit changes to that so that ssl in conjunction with public key just works in such environments.
Resolves #8813