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

131–140 of 265 posts

Re: How Go mitigates supply chain attacks

#131

Post by jchw »

lamontcg wrote: post #121
jchw wrote: post #70

Earlier quoted context omitted.

It’s very subtle, but there are some important differences. For example, lockfiles are not recursive in NPM: the NPM package (usually?) does not contain the lockfile and does not adhere to it when installed as a dependency. It will pick the newest version of dependencies that matches the spec in package.json. Go mod files are used recursively, and rather than try to pick the newest possible version, it will go with t…

How does go deal with the diamond dependency issue when transitively you've a dep on the same package via two different paths?

As far as I understand it... the import path that you use to import a package acts as its identity, and only one version of any given package will be installed. The way that it will determine this is by choosing the lowest version specified in any package that depends on a given package. Major versions of packages are required to have different import paths with Go modules, so when depending on two different major versions of the same package, they are treated effectively as their own package.

Re: How Go mitigates supply chain attacks

#132

Post by skybrian »

infogulch wrote: post #74
lawl wrote: post #64

Earlier quoted context omitted.

> We need packaging tools to aggregate and publish groups of packages that relate to a particular domain, and organizational tools to ensure quality and continuity of these package groups over time Whats stopping you? golang.org/x is kind of like that. Theres nobody stopping you from aggregating packages under foo.bar domain and build a reputation for high quality.

Good question! The thing that the standard library has that I don't is version aggregation . The problem is not publishing under a single domain, the problem is publishing under a single version . Publishing a bunch of packages that I claim are high quality doesn't help users decide which versions to use, they still have to make this decision on a package-by-package basis. Note that I may be in the middle of a big re…

You could sort of do that using a Go module that points to all your other modules. Then anyone who depends on that will get the versions you specify (at a minimum).

But a problem is that they would also download all the modules you point at, whether they use them or not.

To fix that, the package system would need a "soft dependency" where, if a module exists, it must be at least the version indicated.

Re: How Go mitigates supply chain attacks

#133

Post by dezren39 »

typical182 wrote: post #94
goodoldneon wrote: post #92

Earlier quoted context omitted.

Wouldn't build size increase a lot if transitive dependencies were pinned to direct dependency lockfiles? Like if library A says "use version 1.0.0 of library X" and library B says "use version 1.0.1 of library X", then you'd likely end up bundling duplicate code in your build. Not saying the tradeoff isn't worth it, but pinning to dependency lockfiles isn't without downsides.

FWIW, that's not what Go does. In your scenario, a Go binary ends up with a single copy of library X -- the 1.0.1 version. That's because library A is stating "I require at least v1.0.0 of X", and library B is stating "I require at least v1.0.1 of X". The minimal version that satisfies both of those requirements is v1.0.1, and that's what ends up in the binary. That behavior is Go's "Minimal Version Selection" or "MV…

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

Re: How Go mitigates supply chain attacks

#134

Post by skybrian »

codeflo wrote: post #30

The article, and the comments praising this approach, don’t do a great job of explaining how any of this is substantively different from running the likes of yarn install --frozen-lockfile, or cargo build --frozen. Here’s the thing: You can argue about being secure by default and encouraging better CI practices. I’d fully agree it isn’t great that one has to know a somewhat obscure flag to get a secure CI build in th…

I think at most there's pride in their own solution, which is not something anyone should object to - it's pretty good. It's better than some other systems, but no point in being specific.

Not doing specific comparisons is likely a deliberate strategy, since it means the blog post is less likely to go out of date, and it avoids controversy if they get something wrong.

Comparisons will need to be written by people familiar with both systems, and they're likely to go out of date quickly.

Re: How Go mitigates supply chain attacks

#135

Post by skybrian »

coder543 wrote: post #129
skybrian wrote: post #123

Earlier quoted context omitted.

As I understand it, that's true in the simple case. If you have `my_app -> foo -> bar` then there's only one path to bar, and you only get a new bar when you upgrade foo. It's more complicated in general, with diamond dependencies. There needs to be a chain of module updates between you and foo, with the minimum case being a chain of length one where you specify the version of foo directly. So, people do need to pay…

> As I understand it, that's true in the simple case. If you have `my_app -> foo -> bar` then there's only one path to bar, and you only get a new bar when you upgrade foo. This is not correct. You can update bar independent of foo directly from the top-level go.mod file in your project.

Yes, you can do that by adding a direct dependency on foo. I started by talking about when there isn't a direct dependency on foo.

I explicitly talked about having a direct dependency at the end of the second paragraph.

Re: How Go mitigates supply chain attacks

#136

Post by doliveira »

unixbane wrote: post #130

Dependencies being immutable and identified by hash was such an obvious thing 20 years ago. The problem was fitting that into the flow of these crappy UN*X based build systems where to do any mundane task you need to fiddle with files and encodings and semi documented folder heirarchies and use a CLI tool to change other stuff that is too cumbersome to encode directly into files / text. The most obvious concrete inst…

I feel like much of the current software complexity is mostly caused by the pain that is compiling C dependencies and the outdated Unix build and configuration tools.

Re: How Go mitigates supply chain attacks

#137

Post by coder543 »

skybrian wrote: post #135
coder543 wrote: post #129

Earlier quoted context omitted.

> As I understand it, that's true in the simple case. If you have `my_app -> foo -> bar` then there's only one path to bar, and you only get a new bar when you upgrade foo. This is not correct. You can update bar independent of foo directly from the top-level go.mod file in your project.

Yes, you can do that by adding a direct dependency on foo. I started by talking about when there isn't a direct dependency on foo. I explicitly talked about having a direct dependency at the end of the second paragraph.

I'm not talking about direct dependencies. Direct and indirect are all listed in the go.mod file. If they aren't listed there, then they aren't in your final binary. If you delete indirect dependencies from the top-level go.mod, your project will fail to compile.

Re: How Go mitigates supply chain attacks

#138

Post by armchairhacker »

unixbane wrote: post #130

Dependencies being immutable and identified by hash was such an obvious thing 20 years ago. The problem was fitting that into the flow of these crappy UN*X based build systems where to do any mundane task you need to fiddle with files and encodings and semi documented folder heirarchies and use a CLI tool to change other stuff that is too cumbersome to encode directly into files / text. The most obvious concrete inst…

Ah, the old “we’ve already solved this 40 years ago”. Lambdas, immutable-by-default, async/await, etc.

Re: How Go mitigates supply chain attacks

#139

Post by unixbane »

armchairhacker wrote: post #138
unixbane wrote: post #130

Dependencies being immutable and identified by hash was such an obvious thing 20 years ago. The problem was fitting that into the flow of these crappy UN*X based build systems where to do any mundane task you need to fiddle with files and encodings and semi documented folder heirarchies and use a CLI tool to change other stuff that is too cumbersome to encode directly into files / text. The most obvious concrete inst…

Ah, the old “we’ve already solved this 40 years ago”. Lambdas, immutable-by-default, async/await, etc.

Having dependencies not change is literally trivial. Just link to them by hash. Async/await is a pragmatist garbage hack, and does not fit in the archetype you are trying to name.

Re: How Go mitigates supply chain attacks

#140

Post by throwaway894345 »

Friday_ wrote: post #127
throwaway894345 wrote: post #115

Earlier quoted context omitted.

> Software programmer usually need to solve specific task, not worlds problems. If you go too generalized you will need 10x, 100x or 1000x more amount of time and code. Yes, I accept this is true, but your earlier claim was much more specific: that using dependencies at all makes things worse. I gave you a specific example (GUI libraries) but you completely ignored it. How does your 0-dependencies theory survive an e…

It's usually needed only minor part of it. You dont need to code whole GUI library. Only what you need to solve specific task.

No, but if your GUI involves displaying text in multiple languages (i.e., virtually everything), you now need to become an expert in text rendering (which implies a significant breadth of knowledge in linguistics, graphics programming, constraint solving systems [for things like word wrapping], etc).
Post reply on HN