How Go mitigates supply chain attacks • Hacker News Board

Re: How Go mitigates supply chain attacks

#71

Post by nu11ptr » Thu, Mar 31, 2022, 7:07 PM UTC

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…

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

Re: How Go mitigates supply chain attacks

#72

Post by nu11ptr » Thu, Mar 31, 2022, 7:13 PM UTC

Friday_ wrote: post #61

nu11ptr wrote: post #50

Earlier quoted context omitted.

One problem: unless you have an endless amount of time, money, patience, and...did I mention patience? that just isn't a viable approach for anything but the smallest of hobby projects

Build things by KISS principle. Dependencies will complicate system you are building. ( with things like supply chain attacks, bloat, liscensing etc...)

Except KISS is subjective, as are most things. Please don't take this the wrong way, but anyone who touts any one, true "religion" in sw development I have learned to take with 6 grains of salt. There is no one magic way or solution. Everything is trade offs and I've learned this over the last 30 years through trying every new magic elixir that was going to "save us all".

That said, most sw projects are determined by business need. I can't think of a single one I've ever written that hasn't needed dependencies or would have been viable had I not used some. Going to a theory level, there is no reason to think the stdlib is magically immune to the issues of a very popular dependency either. Shun absolutes and make the correct trade offs based on your business goals.

Re: How Go mitigates supply chain attacks

#73

Post by throwaway894345 » Thu, Mar 31, 2022, 7:15 PM UTC

infogulch wrote: post #60

I'm annoyed by the false dichotomy that colors most discussions around package management that there are only two solutions to publishing software packages: 1. a carefully curated professionally maintained standard library, 2. the complete wild west where anything goes. It's not really "false" because this is the reality of how package managers are designed today, but it's false in the sense that it doesn't have to b…

This is kind of interesting. In the Linux world, you have package maintainers who (among other things) vet and vouch for the quality of the packages they maintain. I think there are similar things in the Docker ecosystem these days (since Docker really did/does seem to be the wild west).

It could be interesting if there was a similar concept for Go (and/or other ecosystems), except that instead of actually packaging the packages into artifacts (especially with the licensing headache that entails), it could be essentially a registry of verified package versions. So the "maintainers" in this sense are just validating the dependencies and maintaining a list of the approved dependencies (including their versions/checksums) and then automated tooling could be used by consumers ("consumer" here may or may not imply payment depending on whether this hypothetical venture is open or closed) to identify unverified dependencies in the consumer's project.

I'm sure someone has thought of this already--link me to relevant projects if you know about any.

Re: How Go mitigates supply chain attacks

#74

Post by infogulch » Thu, Mar 31, 2022, 7:15 PM UTC

lawl wrote: post #64

infogulch wrote: post #60

I'm annoyed by the false dichotomy that colors most discussions around package management that there are only two solutions to publishing software packages: 1. a carefully curated professionally maintained standard library, 2. the complete wild west where anything goes. It's not really "false" because this is the reality of how package managers are designed today, but it's false in the sense that it doesn't have to b…

> We need packaging tools to aggregate and publish groups of packages that relate to a particular domain, and organizational tools to ensure quality and continuity of these package groups over time Whats stopping you? golang.org/x is kind of like that. Theres nobody stopping you from aggregating packages under foo.bar domain and build a reputation for high quality.

Good question! The thing that the standard library has that I don't is version aggregation. The problem is not publishing under a single domain, the problem is publishing under a single version. Publishing a bunch of packages that I claim are high quality doesn't help users decide which versions to use, they still have to make this decision on a package-by-package basis. Note that I may be in the middle of a big redesign and some individually-complete packages use the new design but others don't, so you can't just say use the latest of each because they don't all work together yet. In this case I still want to publish each package individually for people who do want fine-grained control, but I wouldn't publish a new version of my "package group" with these versions because they're not integrated yet. My point is that aggregations of verified-interoperable packages is a separate problem domain and existing tools don't suffice to solve it.

Re: How Go mitigates supply chain attacks

#75

Post by throwaway894345 » Thu, Mar 31, 2022, 7:16 PM UTC

lawl wrote: post #64

infogulch wrote: post #60

I'm annoyed by the false dichotomy that colors most discussions around package management that there are only two solutions to publishing software packages: 1. a carefully curated professionally maintained standard library, 2. the complete wild west where anything goes. It's not really "false" because this is the reality of how package managers are designed today, but it's false in the sense that it doesn't have to b…

> We need packaging tools to aggregate and publish groups of packages that relate to a particular domain, and organizational tools to ensure quality and continuity of these package groups over time Whats stopping you? golang.org/x is kind of like that. Theres nobody stopping you from aggregating packages under foo.bar domain and build a reputation for high quality.

I suspect licensing may stop you from doing this, but I'm not an expert. See my sibling comment for an alternative: https://news.ycombinator.com/item?id=30871181

Re: How Go mitigates supply chain attacks

#76

Post by throwaway894345 » Thu, Mar 31, 2022, 7:21 PM UTC

xxpor wrote: post #6

Friday_ wrote: post #2

Keep it simple, just don't use dependencies.

Kind of ironic for a language that was the first that I know about where you can straight up import libraries with a URL directly in your source.

It's not a URL, it's just an identifier that sort-of resembles a URL similar to Kubernetes annotation conventions.

Re: How Go mitigates supply chain attacks

#77

Post by coder543 » Thu, Mar 31, 2022, 7:23 PM UTC

svnpenn wrote: post #41

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.

Dependabot gives you an easy way to review every single commit that went into a dependency update before you merge it.

Dependabot is by far the most convenient way that I’ve seen to actually check that your dependency updates are not overtly malicious.

It's not some tool that just removes your lockfiles behind your back, as you seem to be implying.

Re: How Go mitigates supply chain attacks

#78

Post by azth » Thu, Mar 31, 2022, 7:23 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 used golang at my employer for several years now, and I came out respecting and appreciating the design decision that have and are going into Java/C#/Kotlin much more given the atrocities I've seen written in golang.

Re: How Go mitigates supply chain attacks

#79

Post by azth » Thu, Mar 31, 2022, 7:29 PM UTC

philosopher1234 wrote: post #46

throw_m239339 wrote: post #42

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. 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 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 happening over several years of working in golang. Something that would never have happened in an exception based language.

Re: How Go mitigates supply chain attacks

#80

Post by hobofan » Thu, Mar 31, 2022, 7:31 PM UTC

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…

> Most package managers have lockfiles

> Locking dependencies is, generally, a solved problem across most ecosystems

As someone who is building a package manager for work, and has looked at pretty much every package manager out there (and their ecosystem adoption), I can only say that those don't reflect the current reality of package management (no matter how much I wish it were true).

Bundler was the first mainstream package manager to adopt a lockfile (AFAIK) a mere 12 years ago. Many many language ecosystems predate that and are still lacking lockfiles (or even widespread adoption of a single compatible package manager).

NPM only got lockfiles 5 years ago (after being pressured by yarn). Gradle got them less than 3.5 years ago, and Maven still doesn't have them (though a niche plugin for it exists). The Python ecosystem is still a hot mess, with ~3 competing solutions (Poetry, Pipenv, Conda), of which Conda just got a 1.0 of their decent conda-lock incubation project a month ago, but due to how setuputils works, the cross-platform package management story is broken almost beyond recovery. In Conan lockfiles are still an experimental feature today.

I could go on and on, but I hope that I could paint a picture that while one could argue that with the advent of lockfiles, locking dependencies has become a solved problem _conceptually_, the current status of implementation across ecosystems is still horrible. I'm also constantly amazed about how little love is put into package managers in most language communities, even though they are so crucial for their respective ecosystems.

As far as I can tell nowadays Go does have one of the better package managers, which given their horrible starting point is quite the feat. As a nice side-effect of experiments in the Go package ecosystem, one of the people working on go dep also created one of the best resources around package managers: https://medium.com/@sdboyer/so-you-want-to-write-a-package-m...