npm: More Secure Canary Publishing
Andrew Lisowski
Publishing canary versions comes with some security risks. If your project is private you have nothing to worry about, but if your project is open source there are some security holes.
Attack Vectors
Depending on the build platform you might be able to pass secrets to PR builds for forked repos.
While this makes the developer experience of your project nice, in auto
's case publishing canary versions, it exposes your keys.
An attacker could:
- print secrets
- send secrets to some server
- modify
auto
to publish to the latest tag instead ofcanary
No amount of code can fix these problems.
If your release keys are in everyone's CI builds an attacker can do any number of things to modify what you intend for auto
to do (or any other release method run in the CI).
Solution
The solution for this is actually quite simple:
- Create a test scope that you publish canaries under (ex:
@auto-canary
or@auto-test
) - Create a user that only has access to that scope
- Set the default
NPM_TOKEN
to a token that can publish to that scope (this is used for any pull request) - Set up a
secure
token that is only accessible on the main fork (still namedNPM_TOKEN
)
Step 3 might not be possible on your build platform.
The following are the ways the auto
team knows how to do it.
If you do not see the method for you build platform, please make a pull request!
- CircleCI Context - Contexts provide a mechanism for securing and sharing environment variables across projects. The environment variables are defined as name/value pairs and are injected at runtime.
Usage
To use this work flow in auto
, supply the following configuration to the npm
plugin.
{ "plugins": [ [ "npm", { "canaryScope": "@auto-canary" } ] ] }
{ "plugins": [ [ "npm", { "canaryScope": "@auto-canary" } ] ] }
Now when people make pull requests to your repos:
- your CI can run
auto shipit
- the canary versions will get published under your
canaryScope