When we publish an adaptor, we're not in full control of the dependencies that adaptor uses. Security vulnerabilities in our dependencies might get exposed through our adaptor APIs, and thus open up attack vectors in our workflows.
For example: our google adaptors depend on a thing called node-forge, which I think is something about key signing. Whatever. The version used by our googleapis dependency happens to have a number of security alerts attached to it.
Sometimes we can just update the dependency - ie, bump googleapis to latest, and that will resolve the problem (although we need to test the new adaptor build and that can be hard). But sometimes we can't do that - particularly for older packages we depend on.
We have the option to publish a lockfile with our adaptor packages, which will pin every single dependency version for that adaptor, giving us full control over this. This is called shrinkwrapping.
Benefits:
- We can ensure that when an adaptor is installed, we know exactly what's in it (caveat, we don't really actually know - I mean the data is there but we don't inspect it or do anything about it)
- We can patch and override dependencies of dependencies
Costs:
- This is also a security vulnerability! By locking package versions we don't benefit from security patches that would automatically get installed through semver resolution.
- NPM recommends that libraries don't use shrinkwrapping, because end user applications can't then set their own overrides or benefit from security patches. Usually I'd say that adaptors are libraries, but in the context of our worker and our CLI I don't really think that applies - they're closer to applications
When we publish an adaptor, we're not in full control of the dependencies that adaptor uses. Security vulnerabilities in our dependencies might get exposed through our adaptor APIs, and thus open up attack vectors in our workflows.
For example: our google adaptors depend on a thing called
node-forge, which I think is something about key signing. Whatever. The version used by our googleapis dependency happens to have a number of security alerts attached to it.Sometimes we can just update the dependency - ie, bump googleapis to latest, and that will resolve the problem (although we need to test the new adaptor build and that can be hard). But sometimes we can't do that - particularly for older packages we depend on.
We have the option to publish a lockfile with our adaptor packages, which will pin every single dependency version for that adaptor, giving us full control over this. This is called shrinkwrapping.
Benefits:
Costs: