How Go mitigates supply chain attacks
1–10 of 265 posts
Re: How Go mitigates supply chain attacks
#2Keep it simple, just don't use dependencies.
Re: How Go mitigates supply chain attacks
#3Something 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 actually stems from security-related issues being noted in a low-level module, and the ripple effects caused by that when a bunch of maintainers have to go around bumping lockfiles and versions.
Re: How Go mitigates supply chain attacks
#4Go 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 likely to deeply respect and appreciate it.
Re: How Go mitigates supply chain attacks
#5Keep 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.
Re: How Go mitigates supply chain attacks
#6Keep 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.
Re: How Go mitigates supply chain attacks
#7Something 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…
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, and better consistency between projects.
Re: How Go mitigates supply chain attacks
#8Go 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 couldn't have said it better.
Other ecosystems decided to use lots of little dependencies and I can't imagine a worse engineering decision. This way lies madness.
Re: How Go mitigates supply chain attacks
#9I don't like the authoritative tone of the article. Especially
given the fact that author "conveniently forgets" about
go mod edit
go work
Re: How Go mitigates supply chain attacks
#10Go 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.