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

211–220 of 265 posts

Re: How Go mitigates supply chain attacks

#211

Post by hashhar »

woojoo666 wrote: post #195
typical182 wrote: post #189

Earlier quoted context omitted.

That's not correct. You can unilaterally decide to update the version of E without waiting for anyone. Alternatively, if only C for example decides to update their required version of E, you would get that version of E if you updated your version of C (directly or indirectly), without needing to directly do anything with E yourself. Slightly longer explanation of the mechanics here: https://news.ycombinator.com/item?…

But wouldn't that have the same issue then? Developers decide to update their dependencies to patch any security vulnerabilities, and wind up adding installing node-ipc's malicious update

The difference is that it's an explicit choice instead of other package managers who'd happily install latest compromised versions of packages by default.

Re: How Go mitigates supply chain attacks

#212

Post by PufPufPuf »

coopierez wrote: post #207
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…

To be fair, there are problems that look easy at the first sight, but turn out surprisingly difficult -- and working with time is almost always one of those problems.

Re: How Go mitigates supply chain attacks

#213

Post by woojoo666 »

hashhar wrote: post #211
woojoo666 wrote: post #195

Earlier quoted context omitted.

But wouldn't that have the same issue then? Developers decide to update their dependencies to patch any security vulnerabilities, and wind up adding installing node-ipc's malicious update

The difference is that it's an explicit choice instead of other package managers who'd happily install latest compromised versions of packages by default.

But if its a manual explicit choice, that adds more friction to these patches, and many developers may not update them at all. It's a trade off

Re: How Go mitigates supply chain attacks

#214

Post by morelisp »

smw wrote: post #186
morelisp wrote: post #101

Earlier quoted context omitted.

> Something that would never have happened in an exception based language. Please, over-swallowed exceptions happen all the damn time. Same shit different day. A really common Java problem: T x = foo(); return x.bar(); Now foo() can throw, OK try { T x = foo(); return x.bar(); } catch (Something exc) { return quux(); } You just ate anything from bar(). Instead you gotta do T x; try { x = foo(); } catch (Something exc…

Only with checked exceptions, which I think most of java has made an anti-pattern now?

No, it's got nothing to do with checked exceptions. It's from not wanting all the error-handling noise between the two steps of your happy-path logic.

And at least in extant Java code and many Java programmers I interview, it's not considered an anti-pattern (but I agree it should be).

Re: How Go mitigates supply chain attacks

#215

Post by morelisp »

woojoo666 wrote: post #213
hashhar wrote: post #211

Earlier quoted context omitted.

The difference is that it's an explicit choice instead of other package managers who'd happily install latest compromised versions of packages by default.

But if its a manual explicit choice, that adds more friction to these patches, and many developers may not update them at all. It's a trade off

A manual choice can be easily automated; an automatic choice can be difficult-to-impossible to de-automate.

Re: How Go mitigates supply chain attacks

#216

Post by Tainnor »

WatchDog wrote: post #183
Tainnor wrote: post #23

Most package managers have lockfiles. Yes, npm's decision to have both "npm install" and "npm ci", just so you can confuse and mislead developers, is a bit silly. But Ruby's Bundler, for example, has been refusing to run your code if your lockfile is inconsistent for as long as I remember. Locking dependencies is, generally, a solved problem across most ecosystems (despite node botching its UX). Go doesn't get to cla…

Maven and gradle don't have lockfiles(by default), and have never really had a serious need for them, because dependency declarations generally don't use ranges. The central repositories don't allow versions to be replaced, and artifacts are all signed with PGP keys of the developers(although most people don't verify these). I've never really seen the value in dependency ranges, they make builds more complicated, and…

As far as I know that doesn't solve the problem for transitive dependencies, which can still be resolved to different versions without a lock file.

Re: How Go mitigates supply chain attacks

#217

Post by jchw »

rjmorris wrote: post #172
jchw wrote: post #154

Earlier quoted context omitted.

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.

It didn’t mention one by name, but Rust hasn’t been subject to any widely publicized supply chain attacks. They do, however, mention left-pad by name. I think it can be implied that they really did just mean npm.

Re: How Go mitigates supply chain attacks

#218

Post by WatchDog »

Tainnor wrote: post #216
WatchDog wrote: post #183

Earlier quoted context omitted.

Maven and gradle don't have lockfiles(by default), and have never really had a serious need for them, because dependency declarations generally don't use ranges. The central repositories don't allow versions to be replaced, and artifacts are all signed with PGP keys of the developers(although most people don't verify these). I've never really seen the value in dependency ranges, they make builds more complicated, and…

As far as I know that doesn't solve the problem for transitive dependencies, which can still be resolved to different versions without a lock file.

No it’s the same behaviour for transitive dependencies, if two libraries require different versions of the same transitive dependency, the newer one is chosen. Deterministic no lock file required.

Re: How Go mitigates supply chain attacks

#219

Post by Vendan »

na85 wrote: post #200
Vendan wrote: post #163

Earlier quoted context omitted.

> Am I to understand that it's common to hand-edit the version constraint on a transitive dependency in your go.mod file? No, run `go get @ ` and Go will do it for you.

>No, run `go get @ ` and Go will do it for you. The point GP was making is that it's not a given you'll know that there's a security vuln in a sub-sub-sub-dependency of your app. Is it reasonable to expect developers to manually keep tabs on what could be dozens of libraries that may or may not intersect with the dependencies of any other apps you have on the go? Maybe for Google scale where you can "just throw more…

Well, the easy thing is just let something like Dependabot update your stuff. If you are just wanting "update all my stuff to the latest version", just run `go get -u ./...`?

Re: How Go mitigates supply chain attacks

#220

Post by zeeboo »

woojoo666 wrote: post #197
zeeboo wrote: post #90

Earlier quoted context omitted.

Every change that fixes a security issue implies the existence of a change that introduced the security issue in the first place. Why is bumping a version more likely to remove security issues instead of introduce them? The reason why older is better than newer has more to do with the fact that the author has actually tested their software with that specific version, and so there's more of a chance that it actually w…

Security issues aren't introduced intentionally, oftentimes they are found much later on in code that was assumed to be secure. Like the SSL heartbleed vulnerability. Once a vulnerability like that is discovered, you _want_ every developer to update their deps to the most secure version

My statement had nothing to do with intent. Conversely, once a vulnerability is introduced (intentionally or not), you don't want every developer to update their deps to the newly insecure version.
Post reply on HN