3 ms·

What does the url model bring? Packages are typically considered immutable once published. If I have a particular package e.g. "FooLib.Bar v 1.2.3" then this z

What does the url model bring? Packages are typically considered immutable once published. If I have a particular package e.g. "FooLib.Bar v 1.2.3" then this zip file should _always_ contain the same bits. If I need to change those bits, e.g. to fix a bug then I need to ship e.g. "FooLib.Bar v 1.2.4" Also packages aren't always small. So it makes sense to cache a copy locally. On dev machine "package cache" and in an org's "internal feed" and only check upstream if it's not there. So I shouldn't need to go to the source url to get it. Ideally, I just ask "who has "FooLib.Bar v 1.2.3" for me?" It also means that tampering can be detected with a hash. But the "check upstream" model is now vulnerable to fake new versions.

mythz 6y ago
Using a FQDN is less likely to be unknowingly hijacked when it's a domain they control and use daily. URL references also contain the version number, typically an immutable Git tag reference. They also benefit from just needing to download the source code that's referenced and not the entire package. With Deno you can also optionally host versioned 3rd Party packages on their deno.land/x CDN. URL references are also cached locally on first use and can be used offline thereafter.
michaelt 6y ago
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.
- SideburnsOfDoom 6y 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)

mythz 6y ago

Using a FQDN is less likely to be unknowingly hijacked when it's a domain they control and use daily. URL references also contain the version number, typically an immutable Git tag reference. They also benefit from just needing to download the source code that's referenced and not the entire package. With Deno you can also optionally host versioned 3rd Party packages on their deno.land/x CDN. URL references are also cached locally on first use and can be used offline thereafter.

michaelt 6y ago

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.

SideburnsOfDoom 6y 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)