3 ms·

Stuff keeps moving out of the standard lib related to crypto. First was PGP, now elliptic. Why doesn't Go want to provide stdlib crypto stuff?

kyrra 3y ago
Two reasons I can think of: 1) speed to update it in the case of a bug / security issue. 2) backwards compatibility. Getting a new Go release out is likely a lot more time consuming than bumping up the crypto library outside of there. And those libraries do not require full backwards compatibility compared to the Go standard library. So they can do breaking changes if need back without breaking the Go contract.
- eatonphil 3y ago
  For 1) they create patch releases of Go versions fairly often. So I don't think that makes sense.
  - mseepgood 3y ago
    Perhaps they would prefer not to create them so frequently.
chrsig 3y ago
my bet is it has something to do with Filippo Valsorda having left google, but that's pure speculation on my part. https://github.com/FiloSottile https://github.com/FiloSottile
- FiloSottile 3y ago
  Nope :) I'm still a maintainer, and actually happen to be the one that drove those two deprecations. https://words.filippo.io/full-time-maintainer/ https://words.filippo.io/full-time-maintainer/
  - chrsig 3y ago
    Glad to have my wild speculation disproven :) And glad that becoming a full time independent maintainer is working out for you! Though, in hopes you see this, I have to ask: Is there any sort of plan for if you wanted to step down from a maintainers role of the go crypto packages? You're sort of known as "the" go crypto person, so I guess it occurred to me that your bus factor might be quite high. Any thoughts you can give to assuage fears in that regard? Is there anything the community can do to share the load, short of becoming cryptography experts?
FiloSottile 3y ago
Go is absolutely committed to the cryptography standard library. What's happening is that we're deprecating legacy protocols and APIs to invest resources on packages that better align with the Cryptography Principles [0]. In particular, crypto/elliptic was an unfortunate API that has been deprecated in favor of the new crypto/ecdh. Most applications can migrate (on their own time, as we don't break backwards compatibility even for deprecated packages) and get better security and performance. (A very small portion of applications might need lower level applications, in which case they can use third party modules based on the stdlib internals, like filippo.io/nistec.) You can read more on my Go 1.20 [1] and Go 1.21 [2] posts. [0]: https://golang.org/design/cryptography-principles https://golang.org/design/cryptography-principles [1]: https://words.filippo.io/dispatches/go-1-20-cryptography/ https://words.filippo.io/dispatches/go-1-20-cryptography/ [2]: https://words.filippo.io/dispatches/go-1-21-plan/ https://words.filippo.io/dispatches/go-1-21-plan/

kyrra 3y ago

Two reasons I can think of: 1) speed to update it in the case of a bug / security issue. 2) backwards compatibility. Getting a new Go release out is likely a lot more time consuming than bumping up the crypto library outside of there. And those libraries do not require full backwards compatibility compared to the Go standard library. So they can do breaking changes if need back without breaking the Go contract.

eatonphil 3y ago
For 1) they create patch releases of Go versions fairly often. So I don't think that makes sense.
- mseepgood 3y ago
  Perhaps they would prefer not to create them so frequently.

chrsig 3y ago

my bet is it has something to do with Filippo Valsorda having left google, but that's pure speculation on my part. https://github.com/FiloSottile https://github.com/FiloSottile

FiloSottile 3y ago
Nope :) I'm still a maintainer, and actually happen to be the one that drove those two deprecations. https://words.filippo.io/full-time-maintainer/ https://words.filippo.io/full-time-maintainer/
- chrsig 3y ago
  Glad to have my wild speculation disproven :) And glad that becoming a full time independent maintainer is working out for you! Though, in hopes you see this, I have to ask: Is there any sort of plan for if you wanted to step down from a maintainers role of the go crypto packages? You're sort of known as "the" go crypto person, so I guess it occurred to me that your bus factor might be quite high. Any thoughts you can give to assuage fears in that regard? Is there anything the community can do to share the load, short of becoming cryptography experts?

FiloSottile 3y ago

Go is absolutely committed to the cryptography standard library. What's happening is that we're deprecating legacy protocols and APIs to invest resources on packages that better align with the Cryptography Principles [0]. In particular, crypto/elliptic was an unfortunate API that has been deprecated in favor of the new crypto/ecdh. Most applications can migrate (on their own time, as we don't break backwards compatibility even for deprecated packages) and get better security and performance. (A very small portion of applications might need lower level applications, in which case they can use third party modules based on the stdlib internals, like filippo.io/nistec.) You can read more on my Go 1.20 [1] and Go 1.21 [2] posts. [0]: https://golang.org/design/cryptography-principles https://golang.org/design/cryptography-principles [1]: https://words.filippo.io/dispatches/go-1-20-cryptography/ https://words.filippo.io/dispatches/go-1-20-cryptography/ [2]: https://words.filippo.io/dispatches/go-1-21-plan/ https://words.filippo.io/dispatches/go-1-21-plan/