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

201–210 of 265 posts

Re: How Go mitigates supply chain attacks

#201

Post by steveklabnik »

saghm wrote: post #199
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.

I might be misunderstanding GP, but I think what they're saying is that when package A depends on package B, building package A will use B's lockfile. Assuming that's the case, I think this is generally not how Rust does things, as by default Cargo.lock is explicitly listed in the .gitignore when making a library crate, although there's nothing stopping anyone from just removing that line. I think I remember reading…

> I think this is generally not how Rust does things

That is correct.

> as by default Cargo.lock is explicitly listed in the .gitignore when making a library crate

Even if it is included in the contents of the package, Cargo will not use it for the purpose of resolution.

The "don't check it in" thing is related, but not because it will be used if it's included. It's because of the opposite; that way new people who download your package to hack on it will get their own, possibly different Cargo.lock, so you end up testing more versions naturally. Some people dislike this recommendation and include theirs in the package, but that never affects resolution behavior.

Re: How Go mitigates supply chain attacks

#202

Post by azth »

randomdata wrote: post #142
azth wrote: post #83

Earlier quoted context omitted.

Having worked on golang code bases for several years now, I assure you it's not a theoretical problem. It's not fun to have ignored or overwritten errors that keep the program going as if nothing is happening.

If you overwrite or ignore your variables you're going to have a bad time. Period. That's not unique to errors. I'm not sure you've said anything to convince us that making mistakes around errors alone is anything more than theoretical. Beyond defining an interface named error (early versions didn't even offer that), Go does not have a concept of errors, so I'm not sure it is even possible for there to be a problem s…

Because errors are just return values in golang, and it's not possible to write a linter to guarantee that they're handled, there's always going to be the possibility of them being overwritten by accident. Not to mention due to the lack of composability, you end up with even more hacks like what gorm does, making it even easier to mishandle errors.

> Go does not have a concept of errors

Exactly the problem. There needs to be a notion of error handling in the language.

Re: How Go mitigates supply chain attacks

#203

Post by ehnto »

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…

What if the requirement was pinned specifically to 1.0.0 in order to avoid a bug introduced in 1.0.1. With a package that also requires a minimum 1.0.1, that should be unresolvable set of requirements and your package manager should fail to make a lockfile out of it.

Re: How Go mitigates supply chain attacks

#204

Post by riking »

woojoo666 wrote: post #187
hu3 wrote: post #86

Earlier quoted context omitted.

To be fair the title of the article is "How Go Mitigates Supply Chain Attacks" not how it solves. And I think it does a good job at that. For example if you had any JavaScript package that depended on node-ipc in your project, a simple npm install after cloning the project would download code that tries to corrupt files in your disk if the malicious code determined that your IP was from Russia. (before the malicious…

Doesn't node have lockfiles? Cloning a project and running npm install would install the exact dependencies declared in the lockfile right? To quote the docs[1]: > The goal of package-lock.json file is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated by their maintainers. [1]: https://nodejs.dev/learn/the-package-…

Nope, you need to run `npm ci` to guarantee that you don't write a new lockfile.

Re: How Go mitigates supply chain attacks

#206

Post by randomdata »

azth wrote: post #202
randomdata wrote: post #142

Earlier quoted context omitted.

If you overwrite or ignore your variables you're going to have a bad time. Period. That's not unique to errors. I'm not sure you've said anything to convince us that making mistakes around errors alone is anything more than theoretical. Beyond defining an interface named error (early versions didn't even offer that), Go does not have a concept of errors, so I'm not sure it is even possible for there to be a problem s…

Because errors are just return values in golang, and it's not possible to write a linter to guarantee that they're handled, there's always going to be the possibility of them being overwritten by accident. Not to mention due to the lack of composability, you end up with even more hacks like what gorm does, making it even easier to mishandle errors. > Go does not have a concept of errors Exactly the problem. There nee…

> Because errors are just return values in golang, and it's not possible to write a linter to guarantee that they're handled

That's true of all types, though. Nothing specific to errors applies there. Spend enough time in Go and that's going to bite you, even when the error interface is nowhere to be found. You've still not made clear what's special about errors that makes the concern about errors, not all types, more than theoretical.

> There needs to be a notion of error handling in the language.

Why? The computer doesn't have a concept of errors either. All the computer offers is different states. What Go could offer is more guarantees around ensuring that you've handled different states correctly, but that has absolutely nothing to do with errors specifically.

Now, humans have a concept of error. Of course. We classify specific computer states as being errors. But since the language and computer treat errors and other states as being the exact same thing, why would that human classification of error magically lead you to start making mistakes that you wouldn't make with other states? That doesn't make any sense.

Here's a thought: Stop classifying those states as errors. Call them "happy fun times". Then you won't have whatever mental hangups around errors that are causing you problems specific to errors. Because, from a technical perspective, errors don't exist. They are entirely a human construct. There is nothing about that human construct that should be tripping you up in the tech.

No, there should not be any special concept for errors. Errors are not special. As far as the tech is concerned, errors don't even exist. What Go could do is improve on state management generally. Applicable to not only states you've decided to call errors, but all other states as well. Anything that tries to improve state management for only what you've decided to call errors still leaves all of the exact same problems dangling for every other type. That is poor design and doesn't actually solve the problem.

Re: How Go mitigates supply chain attacks

#207

Post by coopierez »

vlunkr wrote: post #81

The elephant in the room here is NPM, and I think the obvious problem there is the culture. I have a tiny app I've been playing with using create-react-app. There are over 800 directories in node_modules. That absolutely dwarfs the number of any other language I've used. Even in a medium sized rails app, you likely have some awareness of what every dependency is. It's just impossible with npm. One thought I've had to…

It's part of the culture of frontend programming.

In the past I've needed to display a timestamp as something like "n weeks ago" (in a mac app). My first instinct was to write a quick function to do the transform. Then I can tweak it and extend it later to fit my app's needs.

However when I asked the web app team at my company to see their code so I could use the same initial set of intervals, it turns out they use a library to do it. The first instinct of a frontend dev seems to be - even for very tiny, single function solutions - download a library.

Re: How Go mitigates supply chain attacks

#208

Post by hashhar »

riking wrote: post #204
woojoo666 wrote: post #187

Earlier quoted context omitted.

Doesn't node have lockfiles? Cloning a project and running npm install would install the exact dependencies declared in the lockfile right? To quote the docs[1]: > The goal of package-lock.json file is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated by their maintainers. [1]: https://nodejs.dev/learn/the-package-…

Nope, you need to run `npm ci` to guarantee that you don't write a new lockfile.

Also the lockfiles are not recursive. i.e. they don't apply to the dependencies you install or their transitive deps.

Re: How Go mitigates supply chain attacks

#209

Post by throwaway23i92 »

37ef_ced3 wrote: post #4

Go is a distillation of many decades of software engineering experience. The people behind Go (e.g., Russ Cox) have learned from history. The peanut gallery loves to complain about superficial aspects of Go. Typically these are people with little or no actual experience using the language and tools. They fixate on imagined problems that don't matter in practice. But anyone who has used Go full-time for a few years is…

No post body was provided.

Re: How Go mitigates supply chain attacks

#210

Post by mirekrusin »

coder543 wrote: post #160
mirekrusin wrote: post #159

Earlier quoted context omitted.

Npm lockfile will refer to same package because you can't republish npm with the same tag (there is also content hash in lockfile). Referring to version tag in git from go's mod can't guarantee that because you can overwrite tag in git. Am I wrong?

Yes. The go.sum file that sits alongside go.mod keeps track of the hashes so that no modification like that can be made, and dependency fetches actually transparently go through a module proxy/mirror that keeps those same hashes as well, and it will prevent you from getting an altered version of a known module even if you’re starting a new project and don’t have a sum file yet. Versions can’t be republished.

Thanks for clarification, indeed I can see go.sum being checked in on few go package repos I've checked, nice.
Post reply on HN