If a private key is available, the public key can be derived from the private key using scalar multiplication. This is how ecdsa.GenerateKey works by itself - it first generates a private key from the provided random byte stream and then derives a public key from that private key.
I don't see how this can be a security risk, but allowing a public key that has a curve but a nil value is definitely a messy API.
Wouldn't that broken behaviour be a potential security issue by itself?
I do remember Go making backwards incompatible changes in some rare scenarios like that.
(and technically the loopvar fix was a big backwards incompatible change; granted that was done with a lot of consideration)
Wouldn't a nil ECDSA key be a security risk?
If a private key is available, the public key can be derived from the private key using scalar multiplication. This is how ecdsa.GenerateKey works by itself - it first generates a private key from the provided random byte stream and then derives a public key from that private key.
I don't see how this can be a security risk, but allowing a public key that has a curve but a nil value is definitely a messy API.