undefined | Better HN

0 pointsmichaelt5y ago0 comments

For better or for worse, many projects auto-update their dependencies these days.

They do this to address the shortfalls of modern conventions like small packages, continuous release cycles and dependencies nested several layers deep.

So if you were using the internal package FooLib.Bar v 1.2.3 and an attacker posts FooLib.Bar v 1.2.4 to a global repository, anyone using auto-updating will update to it.

0 comments

SideburnsOfDoom5y ago

I don't disagree, but both of these (fully or partly automated updates, and attackers) are fairly recent developments to the model.

Of course, mitigation is needed. Supply chain attacks are a hot topic after SolarWinds.

But identifying a package version solely by a url doesn't seem like the right abstraction to me. IMHO, the metadata is more structured: Name (text), version (SemVer) and also maybe now fields to verify and mitigate these attacks: content hash, source feed, etc.

Even if I run an internal feed that transparently proxies and caches the public one, as well as hosting my company's internal artefacts, the rules now might need to be different between packages?

for e.g. between Newtonsoft.Json (new versions always originate on the public feed, never locally) and "SDCo.GeneralUtils" (new versions always originate on the local feed, never upstream)

j / k navigate · click thread line to collapse