Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/tls: revert CL 107627, which writes memory it does not own #28744
User code creates a tls.Config by initializing various fields
There are methods on tls.Config that clearly modify the Config.
Fields in tls.Config point at other data, which may or may not be
Same for modifying CipherSuites and CurvePreferences.
CL 107627 did something like that: it is assuming that the
Specifically, BuildNameToCertificate is now filling in
At the very least, if you have two different configs sharing the
CL 107627 should be reverted. The original justification said:
If it is important for performance that the parsing be
Then at least the code that cares could pre-populate Leaf
I got too distracted thinking through if there was a scenario where this behavior was globally safe, and didn't stop to think about ownership separation. I agree this is wrong, and that we can make all the performance gain available by optionally using (but not setting)
Mailing a CL for that.
(It also didn't help that it's a