search

yarnpkg / berry

📦🐈 Active development trunk for Yarn ⚒
https://yarnpkg.com
BSD 2-Clause "Simplified" License
7.46k stars 1.12k forks source link

[Feature] Trusted PnP microkernel execution #467

Open larixer opened 5 years ago

larixer commented 5 years ago

Describe the user story

I am an IDE developer and I want to be sure that .pnp.js has the code developed by Yarn v2 authors, and not by some adversary.

Describe the solution you'd like

The @yarnpkg/pnp-loader package is introduced which will verify that microkernel code inside .pnp.js is developed by Yarn v2 authors, prior to requiring and executing it.

In order for the microkernel code to be verifiable, two values are attached to each microkernel code being released:

  1. Cryptographic hash value - for backward security reasons.
  2. Cryptographic digital signature - for forward security reasons.

@yarnpkg/pnp-loader will have in its source code ALL the previous hash values for all the previous microkernel code releases. It will also has the LAST non-compromised digital signature public key.

The verification algorithm is the following:

  1. Check if .pnp.js has microkernel hash value known to @yarnpkg/pnp-loader, if yes - the microkernel was produced by Yarn v2 authors in the past and the microkernel can be executed, if no - proceed to step 2.
  2. Check if .pnp.js microkernel has digital signature that can be verified with public key stored inside @yarnpkg/pnp-loader, if yes - the code was signed by Yarn v2 authors and can be trusted until the key pair is compromised.

The algorithm to change compromised digital signature key pair:

  1. In case digital signature key pair will be compromised, the new key pair should be generated and public key MUST be updated in new version of @yarnpkg/pnp-loader
  2. All the previous microkernel hash values should still be trusted.

The algorithm to revoke past microkernel version due to known security vulnerability in the code:

  1. The microkernel hash codes for the previous microkernel releases that has security vulnerability should be removed from @yarnpkg/pnp-loader

Describe the drawbacks of your solution

Not sure, but the discussion is needed.

Describe alternatives you've considered

The alternative is to not execute microkernel code from .pnp.js, but rather have a library with the code, that reads PnP map and answers to resolve queries itself. With such a library it is far too difficult to support all microkernel behaviour for past releases.

arcanis commented 5 years ago

The alternative is to not execute microkernel code from .pnp.js, but rather have a library with the code, that reads PnP map and answers to resolve queries itself. With such a library it is far too difficult to support all microkernel behaviour for past releases.

We actually already have that! If set to false, the pnpEnableInlining setting will cause Yarn to emit a .pnp.meta.json file which can be consumed through the hydratePnpApi function of @yarnpkg/pnp.

That said I think it's a nice idea - the main problem will be to put markers around the dynamic parts, and validate that it's proper JSON 🤔