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: Document how to make custom cert root list #6267
Labels
Milestone
Comments
Owner changed to @agl. |
Out of luck? In https://github.com/bradfitz/camlistore/blob/master/pkg/client/android/android.go I use x509.NewCertPool() to make my own *tls.Config. |
It's not really about more control, but just making it easier to use the control that is already present. e.g. if I'm on a system that puts the SSL system roots in some weird place, what do I do? When *I* read through the package I didn't find the x509.NewCertPool approach that Brad used, so at the least I think the docs could make it clearer (maybe an example?). |
The question is whether one package you import should be able to override the system x509 location for others. Normally we trust packages to behave but this is a fairly serious thing to be able to change. In package time we use $ZONEINFO. Perhaps a similar environment variable makes more sense than having each program change it, but even then I am a little worried. Certainly we should have a good example. |
Maybe from a safety perspective the API exposed can be limited to only *appending* to the system root list, so it'll only be effective if the system can't find the roots in the usual places. That reduces the attack vector from being able to subvert any cert validation to only being able to permit cert validation when it otherwise would be unable to be validated. But you're right it needs some careful thought. Are we considering one package being able to attack another (e.g. a reflection attack)? I guess that's only relevant if places don't take a *tls.Config but only ever use the default, since you're still able to load arbitrary roots into a custom tls.Config. |
I'm a little worried about attacks but more worried about inadvertent breakage, where a package decides to install its own root list as the "system" list because that's all *it* needs and doing so is easier than preparing a tls.Config, and then other packages that need the standard list break. I also don't think it's so terrible to just edit the source code if you're compiling the standard library for a system with a non-standard place. |
This issue was closed by revision d4d7705. Status changed to Fixed. |
FiloSottile
pushed a commit
to FiloSottile/go
that referenced
this issue
Oct 12, 2018
Fixes golang#6267. LGTM=r, josharian R=golang-codereviews, josharian, r CC=golang-codereviews https://golang.org/cl/61020043
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: