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

41–50 of 265 posts

Re: How Go mitigates supply chain attacks

#41

Post by svnpenn »

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…

> transitive dependencies are automatically updated to pick up security fixes

Does Node do this? That seems like an awful idea. People should be manually updating dependencies, never automatically. Stuff like dependabot need to die.

Re: How Go mitigates supply chain attacks

#42

Post by throw_m239339 »

philosopher1234 wrote: post #39
throw_m239339 wrote: post #36

Earlier quoted context omitted.

Well you can actually put many exception yielding statements in the try, unlike with go where your code is full of "if err:=nil{}" after every potential error. Most of the time when an exception occurs in sequential operations that can fail, you don't really care where it failed exactly, only that the failure was caught. The irony is that Go does have half baked exceptions (panic,recover) on top of that error as valu…

Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better.

> Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better.

No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team.

Ironically I've seen a few Go libs and project trying to re-invent optional types due to the verbosity of Go errors, just like people were trying to roll their own generics with interface {} or code generation before they were added to the core. It's a demonstration that some developers don't like the status quo.

Re: How Go mitigates supply chain attacks

#43

Post by nmilo »

mFixman wrote: post #28
icholy wrote: post #19

Earlier quoted context omitted.

let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }

func ThisCouldUseExceptions() error { err := Exceptions() if err != nil { return terrors.Propagate(err) } err = GeneraliseBetter() if err != nil { return terrors.Propagate(err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return terrors.Propagate(err) } value, err := AlsoTheyHelp() if err != nil { return terrors.Propagate(err) } chained_val, err := WithChaining(value) err = AndPreventAccidental…

Generally I find if you're writing code like that, your code is too high level. Okay, you've propagated errors, but what is the calling code going to do with those errors? I find large functions like that usually have enough context to handle the errors themselves. Errors, after all, are just conditions with a special name. It's not common to propagate conditions up several layers of code, so why do the same with errors?

Re: How Go mitigates supply chain attacks

#44

Post by 0des »

yjftsjthsd-h wrote: post #5
Friday_ wrote: post #2

Keep it simple, just don't use dependencies.

I guess that's fine so long as you're covered by the standard library and/or are willing to reimplement a lot of stuff yourself, but that's a significant trade-off you're asking.

It sounds defensive but Go stdlib is all you need. I believe I'm qualified to say that as last year I challenged myself to only use stdlib, out of several languages I used over the course of the year on big projects, Go was painless and that was a unique experience. So far this year I haven't seen much need to add libraries to my work because everything is already within grasp.

Re: How Go mitigates supply chain attacks

#45

Post by munificent »

infogulch wrote: post #38
munificent wrote: post #15

> There is no way for changes in the outside world—such as a new version of a dependency being published—to automatically affect a Go build. > Unlike most other package managers files, Go modules don’t have a separate list of constraints and a lock file pinning specific versions. The version of every dependency contributing to any Go build is fully determined by the go.mod file of the main module. I don't know if thi…

The author is saying that Go provides the same guarantees with just a package list in the go.mod file that other package managers need both a package list and lock file to solve. go.sum is essentially a distributed / community maintained transparency log of published versions of packages.

Maybe I'm just not familiar with it enough but I don't see how merging a package manifest and lockfile into a single file is a net win.

This means it's no longer clear which dependencies are immediate and which are transitive. It's not clear which versions are user-authored constraints versus system-authored version selections. For dependencies that are transitive, it's not clear why the dependency is in there and which versions of which other dependencies require it.

Other packages separate these into two files because they are very different sets of information. Maybe Go's minimum version selection makes that not the case, but it still seems user-unfriendly to me to lump immediate and transitive dependencies together.

Re: How Go mitigates supply chain attacks

#46

Post by philosopher1234 »

throw_m239339 wrote: post #42
philosopher1234 wrote: post #39

Earlier quoted context omitted.

Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better.

> Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better. No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue…

> No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team.

Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at.

Re: How Go mitigates supply chain attacks

#47

Post by jgod »

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?

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).

Re: How Go mitigates supply chain attacks

#48

Post by 0des »

bjackman wrote: post #22
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…

I've been using Go for a couple of years now and it's funny: I do not love Go, I just work effectively in it. I am not passionate about it, but I recommend it for absolutely all appropriate use-cases. It doesnt go for intellectual satisfaction, it goes for getting shit done. You have to respect it for being so radically bland.

Go is boring and that's appreciated by myself and others in my peer group.

Re: How Go mitigates supply chain attacks

#49

Post by munificent »

philosopher1234 wrote: post #40
munificent wrote: post #34

Earlier quoted context omitted.

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

Go just expects you to manually trigger the updates. Thats all. It still is in favor of updating to take security fixes, so i think your argument is wrong.

Let's say my_app uses package foo which uses package bar.

It turns out there is a security bug in bar. The bar maintainers release a patch version that fixes it.

In most package managers, users of my_app can and will get that fix with no work on the part of the author of foo. I'm not very familiar with Go's approach but I thought that unless foo's author puts out a version of foo that bumps its minimum version dependency on bar, my_app won't get the fix. Version solving will continue to select the old buggy version of bar because that's the minimum version the current version of foo permits.

Post reply on HN