-
Notifications
You must be signed in to change notification settings - Fork 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
Load certificates from systems keychain on darwin #8844
base: maint
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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