Document the security design of yarn, the use of SHA1, and security roadmap

[grempe]

Do you want to request a feature or report a bug?
feature (docs)

What is the current behavior?

Yarn website and blog posts make extensive claims about the security of yarn, going so far as to call it 'Mega Secure' on the homepage of yarn.

https://yarnpkg.com

Mega Secure.
Yarn uses checksums to verify the integrity of every installed package before its code is executed.

The Facebook blog post announcing yarn similarly makes security claims, but provides zero information on the security approach.

https://code.facebook.com/posts/1840075619545360

However, nowhere can I find documented what the security design of yarn is intended to accomplish other than these very generic statements.

Yarn appears to use the SHA1 cryptographic one-way hash function to generate and compare digests of packages. This is not really a checksum.

https://en.wikipedia.org/wiki/Checksum

Please prominently document:

• what is the security roadmap for yarn?
• how does yarn use cryptographic hashes to ensure that packages are unmodified?
• what security threats does this prevent? and which does it not?
• when are hashes generated and when are they compared?
• is there a plan to publish hashes of packages in (signed) server metadata to allow the client to compare against a known source of truth?
• why was the SHA1 hash chosen, when more modern and secure primitives such as SHA256 are recommended by security experts? (for example, SHA1 hashes are no longer allowed in TLS certificates due to security concerns). https://en.wikipedia.org/wiki/SHA-1#Cryptanalysis_and_validation
• does the existing yarn.lock file support the use of other cryptographic hash functions other than SHA1 in the future?
• what plans does the yarn project have for supporting cryptographic signatures for packages in the future?

It seems that now, in the early stages of yarn, is the time to incorporate strong security and signed packages. The claims of 'mega security' without any documentation to support those claims may be considered misleading by those concerned with security.

If the current behavior is a bug, please provide the steps to reproduce.

n/a

What is the expected behavior?

n/a

Please mention your node.js, yarn and operating system version.

n/a

[markstos]

Related to security, it would be relevant to highlight that by default a new reverse proxy has been added to network downloads-- registry.yarnpkg.org. This becomes an additional point of possible compromise for network downloads in addition to registry.npmjs.org. Some may wish to trust yarn as a npm client, but would prefer not to trust an additional layer of network infrastructure that the Yarn project is providing. All the offline support that Yarn provides are a great mitigation of all network-related security issues, but users should be aware of the additional network infrastructure they are trusting when using Yarn.

[Daniel15]

why was the SHA1 hash chosen, when more modern and secure primitives such as SHA256 are recommended by security experts?

Unfortunately not under our control for npm packages at the moment... npm use SHA1, so we need to use SHA1 for npm packages 😢 . For example, see shasum in the JSON returned from https://registry.npmjs.org/babel-standalone

what plans does the yarn project have for supporting cryptographic signatures for packages in the future?

This is something I'd love to see. Debian packages have the right idea: It uses SHA256 for hashes, and the manifest (including the SHA256 hashes) is GPG signed.

[grempe]

Thanks @Daniel15 for the sha1 info. Looks like the npm project is choosing to do nothing about moving to SHA256 at the moment, despite all contributors to this thread agreeing its a good idea. They still closed the issue this summer after two years of discussion saying:

I can’t make any guarantees that this is something that we’ll get to in the next year or so.

npm/npm#4938

I'm not trying to push a specific 'fix'. I think its hard though to hold a conversation about whether or not yarn is 'mega secure', or move forward towards a more secure future, without docs though. It can't be expected that security marketing is just taken on faith and anyone who wants to know more must read the source to decide if its true or not.

I think it is now incumbent on yarn to move this issue forward. It seems to me that npm doesn't see the need, or they think its too hard. I'm not saying other package managers have this all figured out, they don't. Rubygems has had signed packages for years (and intense discussion of how to make them more workable). You know how many use them though? I would hazard a guess that its less than %1 of gems. Why? Too hard to use for both packagers and users. And no good story for the distribution of public keys. @Bascule has had lots of discussions in the Ruby community on the topic.

I look forward to learning more.

[Daniel15]

We could always have our own server that does the hashing, instead of relying on npm to do it. Basically proxy npm's API but add some extra fields for hashes using stronger formats.

You know how many use them though? I would hazard a guess that its less than %1 of gems. Why? Too hard to use for both packagers and users.

Unfortunately I feel like it only really works well if people are forced to do it, otherwise they'll just do whatever's easiest. Very very few people will spend time properly signing their packages if they can get away with not signing them. On Debian and Ubuntu, pretty much all packages are signed, as you see a warning every time you apt-get install or apt-get update or apt-get upgrade if any of the package sources you're using aren't signed (or the user doesn't have the public key installed). This means that if you want to host some Debian packages, you'd better ensure you sign the package source 😄

no good story for the distribution of public keys

dpkg (apt-get) has a command to load a public key from a keyserver, for example this is what we do for the Yarn packages:

apt-key adv --keyserver pgp.mit.edu --recv D101F7899D41F3C3

I don't see why other package managers couldn't just do the same thing

[grempe]

Well, not to get too far off topic (documenting the current state and roadmap for security features of yarn), I think a GPG solution is probably a non-starter. Using a decentralized web-of-trust model would require every yarn user that wants to verify packages to import the gpg key of the package signer, or someone who vouches for the keys of package signers hierarchically. And GPG, and its multiple (not always compatible) versions, is painful for most mortals to use and difficult to support.

Tony (@Bascule) wrote up some really good thoughts on the topic for the Ruby gems community to think about. Sadly, I don't think this ever gained any real traction.

https://tonyarcieri.com/lets-figure-out-a-way-to-start-signing-rubygems

The current solution for signing Ruby gems requires packagers to:

• generate their own key pairs
• publicize that a public key for verification is available on the web somewhere
• instruct people how to retrieve and install a key (with trust of keys left up to each person to decide)
• use a different gem installation command line flag to inform rubygems you want to verify a signature.
• there is no good story for installing a signed gem that has dependencies on a mix of signed and unsigned gems.
• few people in the ruby community know anything at all about this process, or even of its existance.

Read more here:

http://www.benjaminfleischer.com/2013/11/08/how-to-sign-your-rubygem-cert/

http://guides.rubygems.org/security/

You don't want to copy that model.

In any case, I think a good place to start is for the yarn team to justify current security claims in marketing docs, document where they are now vis-a-vis security, and where they would like to go. If no one is thinking about these issues then I think its an opportunity wasted if yarn gains significant mind-share and momentum makes it too hard to change later.

[markstos]

As long as we are wondering some on the topic of security:

• As long as yarn is running a reverse proxy, it could add value by periodically checking the SHAs of cached packages against the SHAs of the exact same package versions upstream. If SHAs differ but the version hasn't changed, that could indicate a recent compromise of the package on one end or the other.
• In related news Mozilla is highlighting retiring SHA-1 today. As part of being "mega secure" it would be great if yarn upgraded from SHA1 as another advantage over npm.

[bernhardreiter]

My suggestion is to split this issue in two or three different ones:

1. document the security approach (and getting the process started)
2. move off SHA1 to something better (recommended is SHA3 keccak for new applications like this one)
3. adding packet signing to the used repository. (Note that OpenPGP as implemented in GnuPG is a good idea and can be used with different trust models).

[Daniel15]

move off SHA1 to something better

We're limited by npm... Their servers provide the hashes, and thus we can't fix the algorithm until npm moves to something better.

[bernhardreiter]

The hash has to be calculated on client side to be saved in yarn.lock and those files are shared to become fully reproducable, they could be extended to additionally include Keccak (=SHA3) hashes or use it alone. There are probably other potential solutions. My suggestion is to not discuss the possibilities here, but in a separate issue.

[Daniel15]

Related: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1 Sent from my phone.

…

On Feb 22, 2017 11:27 PM, "Bernhard E. Reiter" ***@***.***> wrote: The hash has to be calculated on client side to be saved in yarn.lock and those files are shared to become fully reproducable, they could be extended to additionally include Keccak (=SHA3) hashes or use it alone. There are probably other potential solutions. My suggestion is to not discuss the possibilities here, but in a separate issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1169 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFnHXS3bRAFZWtvq4ONI0wlapxpQ3Qkks5rfTTOgaJpZM4KZCeG> .

[rally25rs]

I'm giving a presentation on Yarn at a conference and was looking for actual details to back up this "mega secure" claim. From my own testing, I actually noticed that NPM will check the hash of the downloaded .tgz file before extracting it.

npm ERR! shasum check failed for /var/folders/yf/gcmnw1y96k31lh9ttjhfm8v9ssxkkq/T/npm-7989-60191d85/registry.npmjs.org/getpass/-/getpass-0.1.7.tgz
npm ERR! Expected: 5eff8e3e684d569ae4cb2b1282604e8ba62149fa
npm ERR! Actual:   4d3a2db66b2aee079b690573f2246a6f906a5be4
npm ERR! From:     https://registry.npmjs.org/getpass/-/getpass-0.1.7.tgz

Yarn on the other hand, does not, and passes it off to the extraction library.

yarn install v0.21.3
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/getpass/-/getpass-0.1.7.tgz: invalid distance too far back".

If the underlying extraction library had a vulnerability then it could be exploited under Yarn by a man-in-the-middle returning a malicious .tgz instead of the real one, making Yarn less secure than NPM. What is Yarn actually checking? The hash on each file post-extraction?

---

The "... before its code is executed" phrase is also confusing. To many people that probably means "oh when I require('foo') then Yarn will check it before it loads."

[gsklee]

@kittens @samccone Is it possible for us to have a blog post dedicated to this topic sometime?