3 ms·

Meh, this is a defence in depth measure anyway Edit: also, the supported platforms are ARM and x86. If your code isn’t running on one of those platforms, you p

Meh, this is a defence in depth measure anyway Edit: also, the supported platforms are ARM and x86. If your code isn’t running on one of those platforms, you probably know what you’re doing.

ctoth 10mo ago
Linux Windows and MacOS? Go is supposed to be cross-platform. I guess it's cross-platform until it isn't, and will silently change the semantics of security-critical operations (yes, every library builder will definitely remember to check if it's enabled.)
- YesThatTom2 10mo ago
  If you need this for Windows so desperately why aren’t you offering to add support for that platform? It’s open source. Many advanced Go features start in certain platforms and then expand to others once the kinks are worked out. It’s a common pattern and has many benefits. Why port before its stable? I look forward to your PR.
  - baq 10mo ago
    Absolutely not the right take unless the OP is a security researcher
hypeatei 10mo ago
> Meh, this is a defence in depth measure Which is exactly why it should fail explicitly on unsupported platforms unless the developer says otherwise. I'm not sure how Go developers make things obvious, but presumably you have an ugly method or configuration option like: dangerousAllowSecretsToLeak() ...for when a developer understands the risk and doesn't want to panic.
- deleted 10mo ago
  [deleted]
- kbolino 10mo ago
  This is a sharp-edged tool guarded behind an experimental flag. You are not meant to use it unless you want to participate in the experiment. Objections like this and the other one ("check if it's enabled" -- you can't, that's not what secret.Enabled() means) illustrate that this API may still need further evolution, which it won't get if it's never available to experiment with.
- satellite2 10mo ago
  Alternatively: enclave, err := secret.GetEnclave() // err contains whether the platform doesn't support it enclave.Do(f)

Meh, this is a defence in depth measure anyway Edit: also, the supported platforms are ARM and x86. If your code isn’t running on one of those platforms, you probably know what you’re doing.

ctoth 10mo ago

Linux Windows and MacOS? Go is supposed to be cross-platform. I guess it's cross-platform until it isn't, and will silently change the semantics of security-critical operations (yes, every library builder will definitely remember to check if it's enabled.)

YesThatTom2 10mo ago
If you need this for Windows so desperately why aren’t you offering to add support for that platform? It’s open source. Many advanced Go features start in certain platforms and then expand to others once the kinks are worked out. It’s a common pattern and has many benefits. Why port before its stable? I look forward to your PR.
- baq 10mo ago
  Absolutely not the right take unless the OP is a security researcher

hypeatei 10mo ago

> Meh, this is a defence in depth measure Which is exactly why it should fail explicitly on unsupported platforms unless the developer says otherwise. I'm not sure how Go developers make things obvious, but presumably you have an ugly method or configuration option like: dangerousAllowSecretsToLeak() ...for when a developer understands the risk and doesn't want to panic.

deleted 10mo ago
[deleted]
kbolino 10mo ago
This is a sharp-edged tool guarded behind an experimental flag. You are not meant to use it unless you want to participate in the experiment. Objections like this and the other one ("check if it's enabled" -- you can't, that's not what secret.Enabled() means) illustrate that this API may still need further evolution, which it won't get if it's never available to experiment with.
satellite2 10mo ago
Alternatively: enclave, err := secret.GetEnclave() // err contains whether the platform doesn't support it enclave.Do(f)