"go1.21.6 (released 2024-01-09) includes fixes to the compiler, the runtime, and the crypto/tls, maps, and runtime/pprof packages. See the Go 1.21.6 milestone on our issue tracker for details."
This is dot-dot release with just a few minor fixes. Not sure why it's on the front page, but since I have your attention... here something I noticed just the other day:
> the go command by default downloads and authenticates modules using the Go module mirror
Maybe I'm reading this incorrectly but it sounds as google will be able to see every dependency for every project I ever work on.
This is the second time Go adds something that can be used to spy on developers. Obviously they pinky promise to not abuse it, by why does this eventually happens to every Google product?
The Python foundation can see all the dependencies you download from PyPI, and NPM can see all the dependencies you download from NPM/Yarn. This isn't unusual for a package manager.
If you prefer, you can run your own proxy and configure the Go command to use it instead.
That this can happen in the standard library and stay in a stable release for 5-6 months, in fact very nearly making it to Go 1.22, means that Go's quality assurance pipeline is not adequate for use in production. (The actual bug is in the runtime, but that's irrelevant; it's a runtime optimization for an API offered in the standard library)
It also reopens a larger question, that if the Go teams seriously believes it is okay for a modern programming language to offer no ways whatsoever to enforce immutability or exclusive ownership, leaving programmers to reason about such things themselves throughout every project, then they have to hold themselves to a higher standard to prove that this is reasonable to expect.
Similarly, it is also really concerning that they don't consider this a CVE when it obviously could be; a user receiving a shallow cloned map could modify data affecting other users.
That the Go team does not consider this a headline item, let alone a CVE, let alone something that should change how Go is developed and qualified, is all I need to know about how little they care about production grade software. People choosing to use Go in production should at least know what they're getting themselves into.
cryptos|2 years ago
> What to submit? [...] anything that gratifies one's intellectual curiosity.
https://news.ycombinator.com/newsguidelines.html
Maybe it's just me, but I don't feel very inspired on an intellectual level by news about a patch version ;-)
vlod|2 years ago
From: [0]
"go1.21.6 (released 2024-01-09) includes fixes to the compiler, the runtime, and the crypto/tls, maps, and runtime/pprof packages. See the Go 1.21.6 milestone on our issue tracker for details."
https://go.dev/doc/devel/release#go1.21.minor
kramerger|2 years ago
> the go command by default downloads and authenticates modules using the Go module mirror
Maybe I'm reading this incorrectly but it sounds as google will be able to see every dependency for every project I ever work on.
This is the second time Go adds something that can be used to spy on developers. Obviously they pinky promise to not abuse it, by why does this eventually happens to every Google product?
dharmab|2 years ago
If you prefer, you can run your own proxy and configure the Go command to use it instead.
Private modules don't use the mirror.
justinclift|2 years ago
At least they listened when people complained about the more recent "lets include telemetry in the tool chain" proposal and didn't implement that.
MCUmaster|2 years ago
fl0ki|2 years ago
That this can happen in the standard library and stay in a stable release for 5-6 months, in fact very nearly making it to Go 1.22, means that Go's quality assurance pipeline is not adequate for use in production. (The actual bug is in the runtime, but that's irrelevant; it's a runtime optimization for an API offered in the standard library)
It also reopens a larger question, that if the Go teams seriously believes it is okay for a modern programming language to offer no ways whatsoever to enforce immutability or exclusive ownership, leaving programmers to reason about such things themselves throughout every project, then they have to hold themselves to a higher standard to prove that this is reasonable to expect.
Similarly, it is also really concerning that they don't consider this a CVE when it obviously could be; a user receiving a shallow cloned map could modify data affecting other users.
That the Go team does not consider this a headline item, let alone a CVE, let alone something that should change how Go is developed and qualified, is all I need to know about how little they care about production grade software. People choosing to use Go in production should at least know what they're getting themselves into.
justinclift|2 years ago