design/56986-godebug: add note about security fixes vs deprecations
Copied from discussion at https://github.com/golang/go/discussions/55090#discussioncomment-3657405.
Change-Id: Id1be169e1c172629882d3b6e5b671765eecfa952
Reviewed-on: https://go-review.googlesource.com/c/proposal/+/453498
Reviewed-by: Russ Cox <rsc@golang.org>
diff --git a/design/56986-godebug.md b/design/56986-godebug.md
index c8b59ac..a535990 100644
--- a/design/56986-godebug.md
+++ b/design/56986-godebug.md
@@ -161,7 +161,6 @@
would continue to override both these lines
and the default inferred from the go.mod `go` line.
An unrecognized //go:debug setting is a build error.
- It is also an error
6. Adjust the `go/build` API to report these new `//go:debug` lines. Specifically, add this type:
@@ -253,6 +252,35 @@
This entire proposal is about compatibility.
It does not violate any existing compatibility requirements.
+It is worth pointing out that the GODEBUG mechanism is appropriate for security deprecations,
+such as the SHA1 retirement, but not security fixes, like changing the version of LookPath
+used by tools in the Go distribution. Security fixes need to always apply when building with
+a new toolchain, not just when the `go` line has been moved forward.
+
+One of the hard rules of point releases is it really must not break anyone,
+because we never want someone to be unable to add an urgent security fix
+due to some breakage in that same point release or an earlier one in the sequence.
+That applies to the security fixes themselves too.
+This means it is up to the authors of the security fix to find a fix
+that does not require a GODEBUG.
+
+LookPath is a good example.
+There was a reported bug affecting go toolchain programs,
+and we fixed the bug by making the LookPath change
+in a forked copy of os/exec specifically for those programs.
+We left the toolchain-wide fix for a major Go release precisely
+because of the compatibility issue.
+
+The same is true of net.ParseIP.
+We decided it was an important security-hardening fix but on balance
+inappropriate for a point release because of the potential for breakage.
+
+It's hard for me to think of a security problem that would be so critical
+that it must be fixed in a point release and simultaneously so broad
+that the fix fundamentally must break unaffected user programs as collateral damage.
+To date I believe we've always found a way to avoid such a fix,
+and I think the onus is on those of us preparing security releases to continue to do that.
+
## Implementation
Overall the implementation is fairly short and straightforward.
