How Go mitigates supply chain attacks • Hacker News Board

Re: How Go mitigates supply chain attacks

#21

Post by ______-_-______ » Thu, Mar 31, 2022, 5:44 PM UTC

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…

For a decade+, people complained that go lacks generics. Would you say those were all people with no experience fixated on an imaginary problem that doesn't matter, or were the complaints valid?

Re: How Go mitigates supply chain attacks

#22

Post by bjackman » Thu, Mar 31, 2022, 5:47 PM UTC

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.

Re: How Go mitigates supply chain attacks

#23

Post by Tainnor » Thu, Mar 31, 2022, 5:48 PM UTC

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 claim that it's superior here.

But of course, supply chain attacks are still possible with lock files. Because somebody is going to update your dependencies at some point (often for security reasons). And at that point you might be pulling in a malicious dependency which you haven't carefully vetted (because nobody has time to vet all their dependencies thoroughly nowadays).

That's still an unsolved problem, as far as I know. I don't think that Go has solved it.

Re: How Go mitigates supply chain attacks

#24

Post by ryeguy » Thu, Mar 31, 2022, 5:49 PM UTC

icholy wrote: post #19

laerus wrote: post #12

Earlier quoted context omitted.

Quoted post unavailable.

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

This comparison misses the point. Go requires you to bubble up errors manually, that's the difference.

Re: How Go mitigates supply chain attacks

#25

Post by laurent92 » Thu, Mar 31, 2022, 5:49 PM UTC

geodel wrote: post #10

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…

Agreed. There are some folks very closely associated with other language ecosystems but they spend more time in endlessly critiquing every little thing about Go.

I wonder how there are not more NPM vulnerabilities. We control nothing.

Especially during war.

Re: How Go mitigates supply chain attacks

#26

Post by bigdubs » Thu, Mar 31, 2022, 5:50 PM UTC

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 Node.js ships with what is effectively a very thin standard library for some low level things like interacting with the file system, the process model, some security features like TLS.

Re: How Go mitigates supply chain attacks

#27

Post by lostcolony » Thu, Mar 31, 2022, 5:51 PM UTC

icholy wrote: post #19

laerus wrote: post #12

Earlier quoted context omitted.

Quoted post unavailable.

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

  receive 
     {lack_of_erlang_error_handling_is_a_missed_opportunity, true} -> ok
  after 0 ->
    throw let_it_crash
  end.

Re: How Go mitigates supply chain attacks

#28

Post by mFixman » Thu, Mar 31, 2022, 5:52 PM UTC

icholy wrote: post #19

laerus wrote: post #12

Earlier quoted context omitted.

Quoted post unavailable.

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 = AndPreventAccidentallyIgnoringErrors(chained_val)
        if err != nil {
            return terrors.Propagate(err)
        }
    }

Re: How Go mitigates supply chain attacks

#29

Post by klodolph » Thu, Mar 31, 2022, 5:53 PM UTC

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…

Discussing "what is a lockfile" is a bit of a headache because different languages have different files which do different things. Generally speaking, there's some file which specifies the dependency versions and some file with cryptographic checksums of the all transitive dependencies.

In Go it's go.mod / go.sum. In NPM, it's package.json / package-lock.json. In Rust it's Cargo.toml / Cargo.lock.

Diving into the exact details of what the author is saying is a bit outside my headspace at the moment. I think the author of the article may not actually understand the scenario where Go's package system differs. (I'm not sure I do, either.)

Suppose you have your project, projectA, and its direct dependency, libB. Then libB has a dependency on libC.

If projectA has a lockfile, you get exactly the same versions of libA and libB. This is true for Go, NPM, and Cargo. However, suppose projectA is a new project. You just created it. In Go, the version of libB that makes it into the lockfile will be the minimum version that libA requires, which means that any new, poisoned version of libB will not transitively affect anything that depends on libA, such as projectA. With NPM, you get the latest version of libB which is compatible with libA--this version may be poisoned.

Re: How Go mitigates supply chain attacks

#30

Post by codeflo » Thu, Mar 31, 2022, 5:53 PM UTC

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 those environments.

But claiming in what I perceive to be in parts a somewhat grandiose tone to have reinvented the wheel, when you’re just describing a standard approach, can make you sound uninformed.