How Rust is susceptible to supply chain attacks and what we can do to mitigate the inevitable
23 points by hugoarnal
23 points by hugoarnal
A few years ago, I forked a crate that went unmaintained. I commented on GitHub that I'll take over basic maintenance to keep it working and published the crate under a new name. Over time, various high-profile projects depended on my crate. I'm a random person on GitHub with a literal clown as my profile picture, and yet they just add my crate and ship that. It's amazing. Then again, perhaps their judgement is indeed sensible because I am acutely aware of supply chain attacks and I'll make sure to put in the work that this never happens downstream from me. But how would they know?
that doesn’t seem like sensible judgement on the part of those companies, that seems like blind luck
There might be much to dislike about Go the language. (I'm personally fine with most choices Go makes, but I'm aware it's quite controversial.) But FWIW, what it got right was the comprehensive standard library and the minimal dependency culture that results from it.
Go is a lot more interesting when you ignore the actual language and consider it mostly a giant exercise in engineering tooling development. IMO the language is like, C- tier, but the way they do their tooling, package management and language runtime has changed the world.
Go is my primary language but sometimes I feel like I’m working in some weird mashup of C and awk, I don’t know why but it’s a very strong feeling.
Go is so good on so many dimensions that the language itself almost seems like an afterthought.
I find this interesting because it so does not match my experience. I've luckily moved on from Go, but used it from pre-1.0 to 2020 when the great module transition happened. That wasn't the only tooling fiasco, but was remarkable to me because of how bad it was. Here was the decision tree used to properly version dependencies of a fairly popular Go package at that time:
has the package opted into go modules (i.e. is there a go.mod?)
yes
does the repository use semver?
yes
is the major version <= 1?
yes
=> normal versioning, e.g. github.com/stretchr/testify v1.3.0
no
=> when importing, we need add /vN at the end, e.g., import "github.com/my/mod/v4", and in go.mod it will behave like github.com/my/mod/v4 v4.1.0
no
=> pseudo-versioning will be used, e.g. github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181
no
does the repository use semver?
yes
is the major version <= 1?
yes
=> pseudo-versioning will be used, e.g. github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181
no
=> version will be marked as incompatible, e.g. github.com/zeromq/goczmq v4.1.0+incompatible
no
=> ???