4 ms·
I don't understand the point in using ~/.local/bin and then putting it in your PATH. The point of treating /usr/local/bin and the other root-owned binary direct
by inimino 7y ago
I don't understand the point in using ~/.local/bin and then putting it in your PATH. The point of treating /usr/local/bin and the other root-owned binary directories specially is that they are in your path, which means that if you type "ls" you want to run "ls" and not something untrusted. For that reason, anything you put in your PATH needs to be treated exactly with as much care as anything you install in /bin. The only difference might be that you don't affect other users on the same system, in a multi-user environment (which is increasingly rare). It might be convenient if you wanted to be able to clean up an entire installation by deleting one directory, but it's not a security feature.
Don't install binaries anywhere in your path if you don't trust them or know where they came from. (Also, sibling is correct that first location found wins when searching PATH for a command name.)
Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package. This was, in fact, the norm when npm was new and the community was small and most people knew each other. The only problem is with treating npm like a vetted distro like Debian, and assuming that anything on npm is safe to install without any connection to the author (or 1001 dependencies). That's where everything started to go sideways.
- tomxor 7y ago> anything you put in your PATH needs to be treated exactly with as much care as anything you install in /bin. [...] it's not a security feature. The parent was highlighting how the article points out you can overwrite root files: > "bin": { "/usr/bin/date": "./fake-date" } This is not possible with ~/.local I wouldn't call this a "security feature", but I would call it prudent to not hand over root access to npm packages. > Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package. This is not the problem with npm, the problem is dependencies, and their dependencies and so on. I certainly will never be able to personally vet the 1000 deep nest of dependencies in an npm package I may have to use.