> You can also make a typo when all you need is a package name
"packagename" instead of a full URL is quite a difference. And you are not addressing the other risks.
> On the other hand, with a URL, you can actually inspect the code directly
You can do that with most package managers as they show you the upstream URL.
Expecting every developer and every system engineer to verify every package and every dependency they install is not "just a tradeoff". It's simply impossible.
> since most package managers eventually resolve packages to a URL somewhere, the issues you mention are probably present in other package managers
Some check for the SSL certificate, some use package signing (e.g. APT). Also if the pypi domain expires everybody will know, unlike a random library.
>"packagename" instead of a full URL is quite a difference. And you are not addressing the other risks.
It is more characters, and therefore easier to misspell, but a URL also gives you a domain and probably a namespace for the developer, each of which can act as indicators of trustworthiness and help disambiguate packages with the same or similar names.
If you can't double check your spelling for a package name or you just pick the first Google result, or paste from SO, then you deserve what you get. Domain hijacking, MITM, Unicode shenanigans and such are real risks, but not of URLs as package identifiers per se, so much as risks of distributing packages over the internet, which most if not all do anyway.
>You can do that with most package managers as they show you the upstream URL.
But if you don't have to deal with the URL, chances are you won't, and it's less likely you'll bother to follow it. I'm arguing that, if URLs are dangerous because of their length, then package names alone are dangerous because of their abstraction. I know that I can probably trust including "https://github.com/symfony/symfony" but "symfony" or even "symfony/symfony" alone tells me nothing useful.
>Expecting every developer and every system engineer to verify every package and every dependency they install is not "just a tradeoff". It's simply impossible.
True, but Linus' Law is still basically the security model that's supposed to underpin open source software, even it it's proven not to scale as well as assumed. Someone, somewhere has to know the code is safe, and that's either you or someone you trust, or (as is likely the case with most developers) someone you just assume exists.
>Some check for the SSL certificate, some use package signing (e.g. APT). Also if the pypi domain expires everybody will know, unlike a random library.
There's no reason a package manager using URLs can't also require package servers (which, let's face it, are probably going to be Github and Bitbucket in almost all cases) or maintainers to do something similar. Or at the very least put out warnings the way browsers do about invalid or untrusted certificates or unknown domains. You would lose the freedom of the "wild west" model in its purest form but still not be tied down to a single source of authority.
"packagename" instead of a full URL is quite a difference. And you are not addressing the other risks.
> On the other hand, with a URL, you can actually inspect the code directly
You can do that with most package managers as they show you the upstream URL.
Expecting every developer and every system engineer to verify every package and every dependency they install is not "just a tradeoff". It's simply impossible.
> since most package managers eventually resolve packages to a URL somewhere, the issues you mention are probably present in other package managers
Some check for the SSL certificate, some use package signing (e.g. APT). Also if the pypi domain expires everybody will know, unlike a random library.