Read on Twitter
so it's looking like go's design where dependencies are URLs might have been, correct
to expand on this "dependency confusion" exploit, that's well worth reading, it's a critical, easily exploited, and quite easy to understand supply-chain attack https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
the key concept being exploited here is *late binding*, a technique that's widespread in dynamic and object-oriented programming where a name does not *statically* identify a particular location or implementation, but is resolved to such at runtime
here, "runtime" means whenever your packages get installed
late binding on its own is fine as long as either:
- you fully understand the resolution algorithm, or
- you fully trust all locations that algorithm can resolve to
- you fully understand the resolution algorithm, or
- you fully trust all locations that algorithm can resolve to
node's require('name') function is well-understood; there's a known and well-explained process by which 'name' is resolved to a full path to load a module
other languages have a "load path" of searchable directories but the same idea applies
other languages have a "load path" of searchable directories but the same idea applies
however that works, you can in principle know everything this algorithm *could* load: it's all code that's somewhere on your disk, that you can go and audit
what's less clear, across several package ecosystems, is what the package installer does *at install time* when you have multiple sources configured
and that's where trust comes in. if you only have one source, then you know e.g. the name 'react' resolves to https://www.npmjs.com/package/react
if you have multiple sources, and you don't know how your installer resolves a name across those sources, you have a problem
if you have multiple sources, and you don't know how your installer resolves a name across those sources, you have a problem
because a single name is now ambiguous: it could resolve to one of several locations, and some of those locations are outside your control
when you only use the canonical repo, 'react' resolving to https://www.npmjs.com/package/react is fine, because you know what lives there, who owns it, and you can make a trust judgement about it
