Skip to content

crypto/tls: Clean up semantics of copying/immutability of tls.Config in 1.8. #16492

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.

Sign up for GitHub

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

Jump to bottom
Closed
agl opened this issue Jul 25, 2016 · 6 comments
Closed

crypto/tls: Clean up semantics of copying/immutability of tls.Config in 1.8. #16492

agl opened this issue Jul 25, 2016 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.8

Comments

@agl
Copy link
Contributor

agl commented Jul 25, 2016

A function to copy a tls.Config should probably be exposed in 1.8 because net/http could use it. Also, the current DialWithDialer function copies the config in order to set an SNI value, but that has a complex interaction if the Config is being used for serving. Maybe that's an unreasonable use-case but, if so, what's reasonable could be better documented.
@agl agl self-assigned this Jul 25, 2016
@jboelter
Copy link

also #15771

@tamird tamird mentioned this issue Jul 26, 2016
Closed
@quentinmit quentinmit changed the title Clean up semantics of copying/immutability of tls.Config in 1.8. crypto/tls: Clean up semantics of copying/immutability of tls.Config in 1.8. Jul 29, 2016
@quentinmit quentinmit added this to the Go1.8 milestone Jul 29, 2016
@josharian
Copy link
Contributor

also #16228

@josharian josharian mentioned this issue Aug 29, 2016
Closed
@gopherbot
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Sep 1, 2016
@bradfitz
crypto/tls: add Config.Clone
d24f446 
In Go 1.0, the Config struct consisted only of exported fields.

In Go 1.1, it started to grow private, uncopyable fields (sync.Once,
sync.Mutex, etc).

Ever since, people have been writing their own private Config.Clone
methods, or risking it and doing a language-level shallow copy and
copying the unexported sync variables.

Clean this up and export the Config.clone method as Config.Clone.
This matches the convention of Template.Clone from text/template and
html/template at least.

Fixes #15771
Updates #16228 (needs update in x/net/http2 before fixed)
Updates #16492 (not sure whether @agl wants to do more)

Change-Id: I48c2825d4fef55a75d2f99640a7079c56fce39ca
Reviewed-on: https://go-review.googlesource.com/28075
Run-TryBot: Brad Fitzpatrick <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Andrew Gerrand <[email protected]>
@bradfitz
Copy link
Contributor

bradfitz commented Sep 9, 2016

Also, the current DialWithDialer function copies the config in order to set an SNI value, but that has a complex interaction if the Config is being used for serving.

The net/http package also has its own variant of tls.Config.Clone which configs most but not all fields for the same or similar field race reason, because you can't clone a Config already in use for serving.

tls.Config.CloneClient? Kinda gross.

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 5, 2016
@lmb
Copy link
Contributor

lmb commented Oct 21, 2016

Maybe the right step is to make the exported Clone() skip the SessionTickets* variable? This would break session resumption on cloned Config, but that seems like less of a foot gun than having to discern what kind of copy we want.

Also, I think the title of this issue should be amended to mention that DialWithDialer is currently racy.

@bradfitz
Copy link
Contributor

I think https://golang.org/cl/31595 (which didn't mention this issue) was the fix and the last piece of this bug. Closing.

@golang golang locked and limited conversation to collaborators Oct 22, 2017
@rsc rsc unassigned agl Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.8
Development

No branches or pull requests
7 participants
@bradfitz @agl @josharian @quentinmit @lmb @jboelter @gopherbot