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

101–110 of 265 posts

Re: How Go mitigates supply chain attacks

#101

Post by morelisp »

azth wrote: post #79
philosopher1234 wrote: post #46

Earlier quoted context omitted.

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

The right thing is to automatically maintain error context (e.g. stack traces) which golang fails at. Furthermore, the vast majority of the time you will have a top level handler that will log the error anyway. golang is just introducing boilerplate for the sake of it, with none of the upsides. Not to mention it also makes it easy to accidentally ignore or overwrite errors, I've seen several instance of that happenin…

> 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) {
        return quux();
    }
    return x.bar();
Which is longer and now your happy-path logic is noised up even worse than most Go handling.

Re: How Go mitigates supply chain attacks

#102

Post by adamc »

geodel wrote: post #56
munificent wrote: post #49

Earlier quoted context omitted.

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

You keep harping on old buggy version where Go has been very clear that it is operator's explicit responsibility to have correct/updated/fixed versions of dependency running. It specially does not look good in your case considering you work for Google on a different programing language. If you have a clear point to make then compare it with your approach. Instead of making neutral sounding arguments when they are not…

Don't drag in ad-hominem attacks. If you want to defend Go's approach, explain why having it be the "operator's explicit responsibility" is a good policy, likely to make apps (in general) more secure. The obvious implication of the example given is that, on average, it will be a mess.

Re: How Go mitigates supply chain attacks

#103

Post by klodolph »

munificent wrote: post #97
klodolph wrote: post #85

Earlier quoted context omitted.

> I don't think there's any clear argument you can make on first principles for which of those is actually the case. I don't understand why someone would try to argue from first principles here, it just seems like such a bizarre approach. Anyway, it's not just a security issue. Malicious packages and security fixes are only part of the picture. Other issues: - Despite a team's promise to use semantic versioning, poin…

> Other systems for determining the versions to use are much more unpredictable and hard to understand than estimated (look at Dart and Cargo) I'm one of the co-authors of Dart's package manager. :) Yes, it is complex. Code reuse is hard and there's no silver bullet.

Nice! I hope I wasn't coming across as critical of Dart's package manager, or Cargo for that matter.

Re: How Go mitigates supply chain attacks

#104

Post by tormeh »

jgod wrote: post #47
hrns wrote: post #17

Earlier quoted context omitted.

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

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.

Re: How Go mitigates supply chain attacks

#105

Post by merely-unlikely »

kelnos wrote: post #14
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 haven't used Go full-time, but I have used it on and off for more than a few years. There are certainly things I respect and appreciate about it, but there are also a lot of things that annoy me about it. Some that you might consider "superficial", I consider important. If I'm going to be spending all day in a language, I want the ergonomics of the language itself to work with me, not against me, and Go often does…

"but it also means that module publishers can pull versions (or the entire module) for arbitrary, selfish reasons, and then the community is left with a lot of difficulty"

By default go get will download the source code into the pgk/mod folder. So if a module is pulled by the author, you can just use your copy of the source to fork it.

Re: How Go mitigates supply chain attacks

#106

Post by amtamt »

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…

Perhaps

"A module may have a text file named go.sum in its root directory, alongside its go.mod file. The go.sum file contains cryptographic hashes of the module’s direct and indirect dependencies."

And

"If the go.sum file is not present, or if it doesn’t contain a hash for the downloaded file, the go command may verify the hash using the checksum database, a global source of hashes for publicly available modules."

Should be stressed on. If I committed a dependency version (go.mod) and checksum (go.sum) along with the code, either I get a repeatable build everywhere, or build fails if dependency not found or found to be modified.

I am not sure if all other package managers include checksum with dependency version.

Re: How Go mitigates supply chain attacks

#107

Post by vlunkr »

nu11ptr wrote: post #57

> Unlike most other package managers files, Go modules don’t have a separate list of constraints and a lock file pinning specific versions. The weird thing about the Go devs is there is always that little bit of elitism under the surface that I detect in their writing (whether it be colors in the playground, the GC, etc). I spent years writing Go and have now moved to Rust. What I find odd is the Rust team has done (…

I don't see that elitism in this article. Supply chain attacks are a hot topic right now, so it makes sense for them to make a statement about where the language stands with them. They make compelling points, and they're not calling out specific language or package manager as a comparison.

Re: How Go mitigates supply chain attacks

#108

Post by philosopher1234 »

jchw wrote: post #68
nu11ptr wrote: post #57

> Unlike most other package managers files, Go modules don’t have a separate list of constraints and a lock file pinning specific versions. The weird thing about the Go devs is there is always that little bit of elitism under the surface that I detect in their writing (whether it be colors in the playground, the GC, etc). I spent years writing Go and have now moved to Rust. What I find odd is the Rust team has done (…

This is a pretty genuinely confounding response, and I mean that with absolutely no offense intended. There is a tremendous amount of fighting between devs who prefer Go and Rust, and a tremendous amount of elitism as well, truly from both perspectives. Rust gained a reputation for elitism long before Go did; “Rust Evangelism Strike Force” was never meant to be pejorative, and “Rewrite it in Rust” was never meant to…

Lovely comment. I share your sentiment. Go is truly hated on hacker news these days (and, if you're brave enough to venture there, reviled on r/programming).

Re: How Go mitigates supply chain attacks

#109

Post by jchw »

nu11ptr wrote: post #71
jchw wrote: post #68

Earlier quoted context omitted.

This is a pretty genuinely confounding response, and I mean that with absolutely no offense intended. There is a tremendous amount of fighting between devs who prefer Go and Rust, and a tremendous amount of elitism as well, truly from both perspectives. Rust gained a reputation for elitism long before Go did; “Rust Evangelism Strike Force” was never meant to be pejorative, and “Rewrite it in Rust” was never meant to…

To be clear, I have no issue with anyone who prefers Go. I was speaking about the core devs in particular. I would agree that the users of the language definitely go back and forth "trading blows".

Interesting and apologies for misunderstanding. I didn’t read the article as being elitist, though I can see how it reads as self-congratulatory to a degree. Maybe the matter-of-fact way that Go’s developers state its advantages comes off poorly compared to, for example, coming from the standpoint of trying to explain how they got to their current design based on the challenges. Personally, I find articles like this easier to read because they tend to be more terse when written this way versus some other approaches that are perhaps more humble.

Re: How Go mitigates supply chain attacks

#110

Post by gmfawcett »

amtamt wrote: post #106
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…

Perhaps "A module may have a text file named go.sum in its root directory, alongside its go.mod file. The go.sum file contains cryptographic hashes of the module’s direct and indirect dependencies." And "If the go.sum file is not present, or if it doesn’t contain a hash for the downloaded file, the go command may verify the hash using the checksum database, a global source of hashes for publicly available modules." S…

> the go command may verify the hash

If we're talking about reproducible builds, the word "may" seems concerning here?

Post reply on HN