doc/godebug: allow carve out for GODEBUGs introduced in security releases

[rolandshoemaker]

For backwards compatibility, the GODEBUG policy states thats when compiling a module which declares a version of Go older than a specific GODEBUG flag, that flag will have its default set such that the new behavior is disabled (i.e. panicnil was introduced in 1.21 and defaults to 0, and setting it to 1 restores the pre-1.21 behavior. In a module which declares go 1.20, panicnil will be set to 1 by default).

The Security team sometimes needs to fix dangerous behavior which nonetheless some users may rely on, either because the specific dangerous behavior does not apply to them, or because they are able to safely work around the specific behavior in a way we cannot reasonably impose on all users. In these cases we'd like to introduce a new GODEBUG so that we do not break these particular use cases. The current GODEBUG behavior is not conducive to this, as, since we consider the particular behavior inherently dangerous, we never want the flagged behavior to be enabled by default (regardless of the declared Go version in a module).

I propose we allow a specific carve out from the policy for GODEBUG flags introduced specifically in PRIVATE track security fixes. In these cases the flags would act as if they were introduced in Go 1 (or 1.20, when this new policy was introduced), such that their default is never flipped to enable the old behavior by default. This allows us to require users make an explicit decision to re-enable the dangerous behavior. We expect that the introduction of this class of GODEBUG flags will be extremely rare.

This requires no code changes, and would only require a change in the documented policy.

cc @rsc @golang/security

[rsc]

This seems reasonable to me, and in fact we have already done this once since the policy was written, and at least once before the policy was written. This would not strictly speaking affect upgrades from Go 1.N to Go 1.(N+1) because the behavior would still be consistent (fixed) in both.

/cc @liggitt for Kubernetes

[liggitt]

Allowing for a new GODEBUG flag in a backported security fix defaulting to safe could be reasonable, but exceptions do weaken the ability to "just upgrade" to new Go runtime versions and depend on behavior remaining consistent.

"Inherently dangerous" is fairly vague. Picking some examples from GODEBUG history, I could see someone making the case for all of the following guarding inherently dangerous behavior:

• x509sha1
• execerrdot
• tarinsecurepath
• zipinsecurepath
• tlsmaxrsasize

In that list, only tlsmaxrsasize seems reasonable to me to change by default in backports, and I'm trying to rationalize why ... probably some combination of exposed users (widespread, ~anyone running a server), negative impact (~severe and easy to trigger), and expected or known uses of the changed behavior (~none).

If possible, it would be helpful to describe more specifically the rationale / requirements for determining if the exception proposed here should apply. I'm not sure the type of release a GODEBUG flag was introduced in should be the only consideration.

[FiloSottile]

In that list, only tlsmaxrsasize seems reasonable to me to change by default in backports

FWIW I agree, although it is indeed hard to write down clear guidelines for why.

Beyond the criteria you mention, execerrdot, tarinsecurepath, and zipinsecurepath are about unsafe but somewhat documented behavior. x509sha1 is not urgent in that disclosing the issue does not directly lead to attackers taking advantage of it.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

GODEBUG settings generally apply only to newer Go programs, those that say go 1.N or later in the go.mod where N is the release that introduced some new behavior. Programs naming older versions keep the old behavior.

For security releases, we sometimes need to make a change to defaults but allow access to the old behavior for users who are sure the vulnerability does not apply to them. Such changes would also use GODEBUGs, but the new behavior would apply to all programs, not just go 1.N-or-later programs.

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

GODEBUG settings generally apply only to newer Go programs, those that say go 1.N or later in the go.mod where N is the release that introduced some new behavior. Programs naming older versions keep the old behavior.

For security releases, we sometimes need to make a change to defaults but allow access to the old behavior for users who are sure the vulnerability does not apply to them. Such changes would also use GODEBUGs, but the new behavior would apply to all programs, not just go 1.N-or-later programs.