Go Proposal: Secret Mode

Behavior on Unsupported Platforms & API Design

• Main concern: on non-ARM/x86 or non-Linux platforms the feature silently degrades, so developers might believe secrets are protected when they are not.
• Some argue it should panic or require an explicit “I accept leakage risk” flag on unsupported platforms to avoid a false sense of safety.
• Others note it’s experimental, guarded by a flag, and meant partly to identify existing code that could benefit, so failing hard everywhere would impede experimentation.
• Confusion around secret.Enabled: it only indicates that secret.Do is on the call stack, not that hardware/runtime protections are actually active; documentation was flagged as needing clarification.

Purpose & Threat Model in a GC Language

• Even with GC, secrets can linger in memory (stack, registers, heap copies, GC metadata), or be exposed via process compromise, co-tenant attacks, or physical RAM capture.
• Zeroing stack/registers and eagerly wiping secret heap allocations is framed as defense in depth and a help for certifications (e.g., FIPS 140), not a complete solution.
• Critics argue user-space can’t control context switches or actual physical erasure, so this resembles a “soft HSM” and may be mostly security theater.

Manual Scrubbing vs Language/Runtime Support

• Some suggest just scrambling sensitive variables and using helper patterns (e.g., defer scramble(&key) or a “secret stash” object).
• Counterarguments:
  • Compiler and runtime can copy data (e.g., append making copies, temporaries, registers) beyond the programmer’s control.
  • Without language/runtime support, code becomes brittle, messy, and easy to get wrong, especially in large libraries.

Memory Safety & Cryptography Ecosystem Debate

• Lengthy side discussion on whether Go is “memory safe” given data-race–induced crashes and lack of corruption-free concurrency guarantees, vs the practical absence of real-world memory corruption exploits in pure Go.
• Separate thread on how strong Go’s crypto story is compared to C/C++, Java, .NET, and Rust; praise for Go’s stdlib and ecosystem, but pushback that other languages have richer libraries or better ergonomics (operator overloading, specialized crates).

Implementation, Performance, and Limitations

• secret.Do only helps if references are dropped and the GC runs; globals and leaked pointers are explicitly not covered.
• Some speculate it leverages finalizers/cleanup hooks plus special handling in the GC to eagerly zero marked allocations.
• Overhead and practicality in performance-sensitive crypto paths are open questions.
• Example code in the article is criticized for focusing on ephemeral keys while leaving plaintext unprotected, potentially giving the wrong impression.