OS packages shouldn't be the recommended way to install yarn

[slikts]

Installing yarn using an OS package manager like apt

1. conflicts with nvm, requiring a special flag (not documented, see Document how to install yarn when you use nvm #3255)
2. requires elevated privileges, making it less convenient
3. adding a 3rd party system package repo has system-wide security implications, while global npm packages with nvm are actually just local

The third point is the most important; a security-conscious user should prefer to avoid adding 3rd party system package repos if possible. Using npm to install yarn should not show deprecation warnings, and the yarn docs should not claim that it'd necessarily be less secure, since the opposite can be true.

[Daniel15]

This has been discussed in depth, you can search the repo for previous posts on it (for example, #385).

requiring a special flag (not documented, see #3255)

Anyone is welcome to submit a pull request to update the documentation.

requires elevated privileges, making it less convenient

You can use the shell script or just manually extract the tarball if you want to install without elevation. However, I don't understand the benefit of not requiring elevation, particularly for something that you only do once (after which your regular apt update && apt upgrade keeps you up-to-date). What's the use case?

The third point is the most important; a security-conscious user should prefer to avoid adding 3rd party system package repos if possible.

, and the yarn docs should not claim that it'd necessarily be less secure, since the opposite can be true.

I disagree that the npm package can be more secure than the installer or Debian package. npm has no way of signing packages, so there's no way to verify that the package is actually a legitimate release. Installation via npm is going to continue to be less secure until npm provides some way of signing packages.

The other thing with our tarballs is that we can control exactly which files get included in the tarball, which helps to significantly reduce the size of the tarball. This reduction in footprint is one of the main reasons we were able to get Yarn included in the official Node.js Docker images.

I'm going to close this issue since it's a discussion rather than a bug or feature request, but feel free to post comments here if you'd like to continue the discussion. Thanks!

[slikts]

I don't see discussion in the issue you linked, they just state (or overstate) the issues with npm.

npm global packages aren't necessarily installed system-wide, and there's no good reason to push them to be system-wide. You call npm packages 'special snowflakes', but this actually makes yarn stand out in that it doesn't play nice with common local node setups like nvm.

Signing in npm would be nice, but it's not a particularly significant issue (and ultimately only as secure as the TLS connection used to download the key), and using it to call yarn more secure just ignores the drawbacks using system packages have, such as having a system-wide security impact. A system package repo being compromised means system packages can be overriden the next time the user updates their system packages, while npm being compromised with a local setup like nvm would take many more steps to lead to user system compromise. Moreover, the security of a major project like npm is more trustworthy than for one like yarn.

This is a feature request to remove misleading statements about security from the yarn docs and to remove the deprecation warning from the yarn npm package. It'd be helpful if the issue could be reopened.

[Daniel15]

Signing in npm would be nice, but it's not a particularly significant issue (and ultimately only as secure as the TLS connection used to download the key),

You can download keys from a key server instead of downloading them over HTTP, if you wanted to.

. A system package repo being compromised means system packages can be overriden the next time the user updates their system packages

They're much more difficult to compromise though, as the attacker would need the GPG key used to sign the repo.

npm being compromised with a local setup like nvm would take many more steps to lead to user system compromise

Most users have their Node.js and npm bin directory on their PATH so system compromise could be done just by installing a malicious npm package globally (or even a package having a post-install command that modifies the environment). It's significantly easier for a rogue npm package to do something malicious without being detected.

and to remove the deprecation warning from the yarn npm package.

The npm package has various other issues though, unrelated to security. For one, we don't control what gets bundled (even if we control it for Yarn itself, we can't control the dependency packages) which results in a significantly larger installation footprint. Also, versions are not locked down.

Some issues are solvable with an npm shrinkwrap file, but that introduces its own issues. It looks like npm v5 will have a better lockfile format, at which point we could look at better support for the Yarn npm package.

For now, the fact that npm doesn't check GPG signatures combined with the fact that installations are not repeatable/deterministic means that it's not ideal for us to suggest it as a supported installation method.

[slikts]

You can download keys from a key server instead of downloading them over HTTP, if you wanted to.

The key fingerprint is still only authenticated using a TLS CA, so the only advantage of using signed system packages is that the public key gets cached when adding the repo.

Most users have their Node.js and npm bin directory on their PATH so system compromise could be done just by installing a malicious npm package globally (or even a package having a post-install command that modifies the environment).

You're still conflating 'global' with 'system-wide', which does not apply to setups where npm only uses local user privileges. A local npm setup does not have a system-wide security impact, while adding a system package repo does. Using yarn's system package repo requires entrusting the system to the repo maintainers, so claiming that this would necessarily be more secure is questionable. I personally find it more reasonable to trust the security of a large project like npm than yarn.

[Daniel15]

so the only advantage of using signed system packages is that the public key gets cached when adding the repo

Yeah, the idea is that you only add the key once, and then you can be sure that all future releases were signed using that same key.

You're still conflating 'global' with 'system-wide', which does not apply to setups where npm only uses local user privileges

That's a reasonable point. I guess it would be nice for dpkg, rpm, etc. to have some concept of "local packages" that are not installed system-wide. However, if that's what you're worried about, you could just manually extract the Yarn tarball after verifying its GPG signature.

A local npm setup does not have a system-wide security impact

Does that make much of a difference if the npm global package directory is on your PATH though? You can still get malicious executables from an npm package.