Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.21.6 Released

go.dev

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Go 1.21.6 Released

#11

Post by dharmab »

kramerger wrote: post #8
dharmab wrote: post #6

Earlier quoted context omitted.

It's needed to provide checksums for each module. It also significantly improves performance and prevents a left-pad situation. https://go.dev/blog/module-mirror-launch

These are GIT repositories, they have their own cryptographically unique identifiers. No need to send your data to a third-party to get it confirmed. Maybe I'm missing something, but this whole operation feels like a huge infrastructure paid by Google for something that is not needed.

Git history can be rewritten or deleted e.g. by the git rebase command. The mirror's checksum DB is independent and prevents your build from breaking or being altered if a dependency is manipulated or deleted.

As sibling comment notes, Git's hashes are not secure: https://shattered.it

Re: Go 1.21.6 Released

#12

Post by justinclift »

kramerger wrote: post #2

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 ad…

Yeah, people complained fairly loudly about this back when it was implemented, but the Go team just completely ignored the problem.

At least they listened when people complained about the more recent "lets include telemetry in the tool chain" proposal and didn't implement that.

Re: Go 1.21.6 Released

#13

Post by fl0ki »

This one bug greatly undermined my confidence in Go forever: https://github.com/golang/go/issues/64474

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.

Re: Go 1.21.6 Released

#14

Post by justinclift »

ratorx wrote: post #10
kramerger wrote: post #8

Earlier quoted context omitted.

These are GIT repositories, they have their own cryptographically unique identifiers. No need to send your data to a third-party to get it confirmed. Maybe I'm missing something, but this whole operation feels like a huge infrastructure paid by Google for something that is not needed.

> cryptographically unique Git uses SHA1 which is pretty far from cryptographically secure. It’s unlikely that’s the sole reason for having a separate checksum database though.

Doing some searching around online, it seems like git introduced sha256 support several years ago.

Re: Go 1.21.6 Released

#15

Post by justinclift »

fl0ki wrote: post #13

This one bug greatly undermined my confidence in Go forever: https://github.com/golang/go/issues/64474 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 offere…

That issue on GitHub isn't locked. You could ask them about security implications on it.

Re: Go 1.21.6 Released

#16

Post by dharmab »

justinclift wrote: post #14
ratorx wrote: post #10

Earlier quoted context omitted.

> cryptographically unique Git uses SHA1 which is pretty far from cryptographically secure. It’s unlikely that’s the sole reason for having a separate checksum database though.

Doing some searching around online, it seems like git introduced sha256 support several years ago.

Only for some local operations- git protocol still uses SHA-1 for compatibility with old clients, and existing SHA-1 objects in old repositories aren't converted.
Post reply on HN