doc/godebug: allow carve out for GODEBUGs introduced in security releases #63741
Comments
rsc
changed the title
|
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 |
|
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:
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. |
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. |
|
Based on the discussion above, this proposal seems like a likely accept. GODEBUG settings generally apply only to newer Go programs, those that say 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 |
|
No change in consensus, so accepted. 🎉 GODEBUG settings generally apply only to newer Go programs, those that say 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 |
rsc
changed the title
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.
panicnilwas introduced in 1.21 and defaults to0, and setting it to1restores the pre-1.21 behavior. In a module which declaresgo 1.20,panicnilwill be set to1by 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
The text was updated successfully, but these errors were encountered: