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

How Go mitigates supply chain attacks

go.dev

Post reply on HN
Print view View original

171–180 of 265 posts

Re: How Go mitigates supply chain attacks

#171

Post by riwsky »

munificent wrote: post #34
klodolph wrote: post #29

Earlier quoted context omitted.

Discussing "what is a lockfile" is a bit of a headache because different languages have different files which do different things. Generally speaking, there's some file which specifies the dependency versions and some file with cryptographic checksums of the all transitive dependencies. In Go it's go.mod / go.sum. In NPM, it's package.json / package-lock.json. In Rust it's Cargo.toml / Cargo.lock. Diving into the exa…

> any new, poisoned version of libB Conversely, you will get any old security-buggy version of libB instead. Most package managers when adding a new dependency assume newer versions are "better" than older versions. Go's minimum version system assumes older is better than newer. I don't think there's any clear argument you can make on first principles for which of those is actually the case. You'd probably have to do…

The code itself isn’t the only risk factor; it’s weighted by others, like discoverability, which are asymmetric in time. If the white hats fix an issue in version n+1, they’re going to make sure people know. If black hats (or normal devs making a mistake) introduce an issue, no one will tell you about it.

I.e. even if both strategies win just as often, min-version pulls ahead by taking less of a hit from losses.

Re: How Go mitigates supply chain attacks

#172

Post by rjmorris »

jchw wrote: post #154
steveklabnik wrote: post #149

Earlier quoted context omitted.

This really depends on the specific package manager: if you're building an application in Rust, its lockfile will contain the full tree of dependencies, locked to a specific version.

Yes, this is true; I think the article is definitely making the distinction vs NPM and not Rust.

The article seemed to go out of its way not to mention any specific package manager or ecosystem. So I think comparing to Rust is completely reasonable.

Re: How Go mitigates supply chain attacks

#173

Post by [deleted] »

lamontcg wrote: post #168
coder543 wrote: post #161

Earlier quoted context omitted.

I'm fairly sure Go Modules does not support what you’re describing. It specifically avoided having a SAT solver (or something similar), unlike most package managers. You specify a minimum version, and that’s it. 1.8 would be selected because it is the highest minimum version out of the options 1.5 and 1.8 that the dependencies require. Unless you edit your go.mod file to require an even higher version, which is an op…

Well after 12 years of using ruby and bundler and maintaining a bundler-ish depsolver at work, and playing around a bit with cargo, I can say that it is becoming clearer as to why I don't grok go modules at all. The lack of a depsolver is a curious choice... I don't think my example was remotely "broken" at all, that's just another day doing software development.

[deleted]

Re: How Go mitigates supply chain attacks

#174

Post by tgsovlerkhgsel »

One downside of such pinning of versions is that if one of your transitive dependencies has a security vulnerability affecting your package, your package will remain affected until you update.

As I understand it dependencies-of-dependencies are fetched from the config provided by the library that includes the dependency, in the case of a transitive dependency, everyone between you and the vulnerable package needs to update, and they need to do so in order (i.e. if you depend on A, A depends on B, B depends on C, and C fixes a vulnerability, then first B, then A have to update in order for you to pull in the change).

Re: How Go mitigates supply chain attacks

#175

Post by tgsovlerkhgsel »

hrns wrote: post #17
bigdubs wrote: post #7

Earlier quoted context omitted.

There is a deeper strategy here with go vs. node; having a standard library maintained by professionals. I would rather build on a common set of libraries secured by people who are paid full-time to maintain them, and maybe have slightly worse ergonomics, than have a community of libraries that come and go and have inconsistent quality. This standard library approach yields fewer dependencies, fewer changes over time…

Isn't Node API an equivalent of go standard library?

The Fetch API, supported by browsers for over 5 years now, is only now making it into the official Node API https://blog.logrocket.com/fetch-api-node-js/

Re: How Go mitigates supply chain attacks

#176

Post by coder543 »

lamontcg wrote: post #168
coder543 wrote: post #161

Earlier quoted context omitted.

I'm fairly sure Go Modules does not support what you’re describing. It specifically avoided having a SAT solver (or something similar), unlike most package managers. You specify a minimum version, and that’s it. 1.8 would be selected because it is the highest minimum version out of the options 1.5 and 1.8 that the dependencies require. Unless you edit your go.mod file to require an even higher version, which is an op…

Well after 12 years of using ruby and bundler and maintaining a bundler-ish depsolver at work, and playing around a bit with cargo, I can say that it is becoming clearer as to why I don't grok go modules at all. The lack of a depsolver is a curious choice... I don't think my example was remotely "broken" at all, that's just another day doing software development.

> I don't think my example was remotely "broken" at all, that's just another day doing software development.

It's not the norm for me. If this is what you consider to be the norm, then this kind of statement doesn't make me feel any better about Ruby.

I will say that Bundler is one of the better package managers, but the existence of the constraint solver doesn't fix this problem -- Bundler doesn't allow you to have multiple versions of a single dependency. The problem is fundamentally the dependency not maintaining its compatibility guarantees, which I would definitely call "broken". Sometimes breakage is unavoidable, like with security fixes that you want to be available even to users of existing SemVer versions, but it should not be a common situation.

Re: How Go mitigates supply chain attacks

#177

Post by hu3 »

tgsovlerkhgsel wrote: post #174

One downside of such pinning of versions is that if one of your transitive dependencies has a security vulnerability affecting your package, your package will remain affected until you update. As I understand it dependencies-of-dependencies are fetched from the config provided by the library that includes the dependency, in the case of a transitive dependency, everyone between you and the vulnerable package needs to…

You can force newer transient dependencies: https://stackoverflow.com/questions/70100325/force-a-transit...

Re: How Go mitigates supply chain attacks

#178

Post by tsimionescu »

lstamour wrote: post #147
dezren39 wrote: post #133

Earlier quoted context omitted.

how are you not describing package.json right now what is the difference

The difference is the npm ecosystem actively encourages automatically following SemVer because by default it uses a ^ to prefix the version number. https://heynode.com/tutorial/how-use-semantic-versioning-npm... The practice of dependencies’ dependencies being specified using SemVer version constraints to auto-accept minor or patch changes is the difference compared to Go, and why lockfiles will not always save you i…

> The difference is the npm ecosystem actively encourages automatically following SemVer because by default it uses a ^ to prefix the version number.

So does Go. In fact, Go only supports the equivalent of ^, there is no way to specify a dependency as '=1.2.3'. That is, whenever you have two different dependencies which use the same dependency at different (semver compatible) versions, go mod will always download the newer of the two, effectively assuming that the one depending on an older version will also work with the newer.

The only difference in this respect compared to NPM (and perhaps also Cargo or NuGet? I don't know) is that Go will never download a version that is not explicitly specified in some go.mod file - which is indeed a much better policy.

Re: How Go mitigates supply chain attacks

#179

Post by coder543 »

tormeh wrote: post #104
jgod wrote: post #47

Earlier quoted context omitted.

Yes but it's super barebones. Its successor, Ryan Dahl's second attempt at JS runtime, Deno, has a much fuller standard library (inspired by Go).

I wish we'd stop trying to make broken languages work. This feels like hill-climbing into the strangest local optimum possible. JS is not the best example of an interpreted language. Wouldn't it be better to put Python in the browser than to put JS on the server? Can't wait for WASM to be a first-rate citizen on the web so we don't have to deal with this anymore.

I think you would be surprised to learn that more developers love TypeScript than Python these days, according to one popular survey.[0]

All of this is subjective, of course. WASM isn't going to make Python the language of choice for browsers any time soon.

[0]: https://insights.stackoverflow.com/survey/2021#section-most-...

Re: How Go mitigates supply chain attacks

#180

Post by dezren39 »

bigdubs wrote: post #7
glenjamin wrote: post #3

Something this articles glosses over is that some of these approaches, especially the way 'All builds are “locked”' is achieved with minimum version selection, and “A little copying is better than a little dependency” are tradeoffs against an alternative security model, where transitive dependencies are automatically updated to pick up security fixes. Part of the churn and noise in the Node.js dependency ecosystem ac…

There is a deeper strategy here with go vs. node; having a standard library maintained by professionals. I would rather build on a common set of libraries secured by people who are paid full-time to maintain them, and maybe have slightly worse ergonomics, than have a community of libraries that come and go and have inconsistent quality. This standard library approach yields fewer dependencies, fewer changes over time…

so, cathedral vs bazaar
Post reply on HN