Skip to content
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

crypto/x509: export systemRootsPool or equivilant #13335

Closed
phemmer opened this issue Nov 20, 2015 · 6 comments
Closed

crypto/x509: export systemRootsPool or equivilant #13335

phemmer opened this issue Nov 20, 2015 · 6 comments
Assignees
Milestone

Comments

@phemmer
Copy link

@phemmer phemmer commented Nov 20, 2015

I frequently have the need to add a custom CA cert to a go app (both my own apps, along with third party apps I run across). Currently you can create your own *x509.CertPool and add the CA cert to it, but now you can't verify using the system provided CAs.
Since the code behind systemRootsPool has a lot of os/distro-specific logic, it would be good to use this logic instead of having to copy/implement it within the app.

If there is a concern about exposing this pool, and code being able to mutate it, then perhaps we could get something similar to x509.initSystemRoots, but which would return a new copy every time it's called.

Edit: After some thought, returning a new CertPool is better. As there is no way to copy a CertPool, it would otherwise be impossible to add a CA cert to the pool without the cert shared everywhere.

@phemmer phemmer changed the title export crypto/x509.systemRootsPool or equivilant crypto/x509: export systemRootsPool or equivilant Nov 20, 2015
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Nov 20, 2015

I've been in the same position and wanted the system root store.

/cc @agl for any thoughts

@luan
Copy link
Contributor

@luan luan commented Mar 29, 2016

@bradfitz @ianlancetaylor - I'm a little confused with the tags that were applied to the issue. On one hand it seems like we have no plans of solving the issue, on the other it seems like we want to solve it by Go1.7. Could you please clarify that?

Thanks,
@luan

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 29, 2016

We don't have meetings to coordinate these tags.

I set the milestone to "unplanned", meaning that it was probably a good idea but nobody was actually working to implement it. @bradfitz set the milestone to "go1.7", meaning (I assume) that he thinks we should implement this for the 1.7 release. But somebody still has to do the work.

If you want to work on this, you should do so regardless of the milestone.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 29, 2016

(I often change things from Unplanned to Go 1.7 if I want it myself and am willing to do the work if nobody else gets to it first)

@bradfitz bradfitz self-assigned this Mar 30, 2016
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 30, 2016

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 30, 2016

CL https://golang.org/cl/21293 mentions this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.