One thing that makes me unsure about this proposal is the silent downgrading on unsupported platforms. People might think they're safe when they're not.

Go has the best support for cryptography of any language

▲ fastest963 4 days ago | parent | next [-]

I'm not sure there's a realistic alternative. If you need to generate a key then it has to happen somehow on unsupported platforms. You can check Enabled() if you need to know and intend to do something different but I assume most of the time you run the same function either way you'd just prefer to opt into secret mode if it's available.

▲ kbolino 12 hours ago | parent | next [-]

This is not what secret.Enabled() means. But it probably illustrates that the function needs to be renamed already. Here's what the doc comment says:

  // Enabled reports whether Do appears anywhere on the call stack.

In other words, it is just a way of checking that you are indeed running inside the context of some secret.Do call; it doesn't guarantee that secret.Do is actually offering the protection you may desire.

	▲	cafxx 7 hours ago \| parent \| next [-]
		That's not how it's implemented (it returns false if you're inside a Do() on a unsupported platform), although I agree the wording should be clearer.
	▲	draw_down 8 hours ago \| parent \| prev [-]
		[dead]

▲ awithrow 4 days ago | parent | prev [-]

Why not just panic and make it obvious?

	▲	kbolino 12 hours ago \| parent [-]
		One of the goals here is to make it easy to identify existing code which would benefit from this protection and separate that code from the rest. That code is going to run anyway, it already does so today.

▲ alanfranz 4 hours ago | parent | prev | next [-]

I'd probably want some way to understand whether secret.Do is launched within a secret-supporting environment so that I'm able to show some user warning / force a user confirmation or generate_secrets_on_unsupported_platforms flag.

But, this is probably a net improvement over the current situation, and this is still experimental, so, changes can happen before it gets to GA.

▲ samdoesnothing 4 days ago | parent | prev | next [-]

Does it? I'm not disputing you, I'm curious why you think so.

▲

pants2 3 days ago | parent [-]

Not OP, but Go has some major advantages in cryptography:

1. Well-supported standard libraries generally written by Google

2. Major projects like Vault and K8s that use those implementations and publish new stuff

3. Primary client language for many blockchains, bringing cryptography contributions from the likes of Ethereum Foundation, Tendermint, Algorand, ZK rollups, etc

▲

adastra22 11 hours ago | parent | next [-]

Do you mean “best support for cryptography in the standard library”?

Because there is tremendous support for cryptography in, say, the C/C++ ecosystem, which has traditionally been the default language of cryptographers.

	▲	Mawr 6 minutes ago \| parent \| next [-]
		And since any language can call those C/C++ libraries, all languages are equally good at cryptography! Thanks for the "insight".
	▲	fsmv 8 hours ago \| parent \| prev [-]
		Yeah the standard library crypto package is really good and so is the tls package. There's also golang.org/x/crypto which is.seprate because it doesn't fall under the go compatibility guarantee. You can do all kinds of hashes and generate certs and check signatures and do aes encryption all built in and accessible. There's even lower level constant time compare functions and everything. I'm a big fan of the go standard library + /x/ packages.

▲

int_19h 44 minutes ago | parent | prev [-]

"The best" is still a strong claim. How does it stack up against Java or C#, for example?

▲ oncallthrow 14 hours ago | parent | prev | next [-]

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 14 hours ago | parent | next [-]

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 4 hours ago \| parent [-]
		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.

▲ hypeatei 13 hours ago | parent | prev [-]

> 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.

	▲	kbolino 12 hours ago \| parent \| next [-]
		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.
	▲	13 hours ago \| parent \| prev [-]
		[deleted]

▲ treyd 2 hours ago | parent | prev [-]

> Go has the best support for cryptography of any language

This isn't true at all.

Writing cryptography code in Go is incredibly annoying and cumbersome due lack of operator overloading, forcinforcing you to do method calls like `foo.Add(bar.Mul(baz).Mod(modulus)).Mod(modulus)`. These also often end up having to be bignums instead of using generic fixed-size field arithmetic types. Rust has incredibly extensive cryptographic libraries, the low-level taking advantage of this operator overloading so the code ends up being able to following the notation in literature more closely. The elliptic_curve crate in particular is very nice to work with.