top | item 21565330

Publish NPM Package with GitHub Actions

47 points| pafo | 6 years ago |juffalow.com | reply

28 comments

order
[+] NathanKP|6 years ago|reply
Note that you need to be very careful about this if you have a public repository that accepts PR's from third parties. There is nothing stopping someone from adding this via a PR:

    - name: Give me this person's NPM token
      run: cat ~/.npmrc
Even if you have it locked down so they can't see the build output, they could just add a curl command to post the contents of your .npmrc file to their server.

A number of open source projects have been hacked this way in the past. This is why I keep my NPM publish entirely isolated from the Github repo. I review every PR that is submitted to me carefully, but don't want any chance of accidentally merging in a malicious PR that will compromise my NPM packages.

[+] amenod|6 years ago|reply
I like the way GitLab solves this. You mark your secrets ("CI/CD env vars") as protected, then only protected branches and tags can use them. When someone has right to merge or push to a protected branch, thay of course gain access to these vars, but if you don't allow anyone to do this, you are pretty safe.
[+] est31|6 years ago|reply
Yes this is a problem in Rust-land too. crates.io doesn't support user tokens to be limited to a crate only [1], but gives access to all the crates an user has access to. So if the token leaks, attackers have access to all your crates. For the cpal crate we worked around the issue by creating a new github user that has only access to the cpal crate (and maybe in the future a few other crates in the same org) but nothing more [2]. This solution isn't really good tho.

[1]: https://github.com/rust-lang/crates.io/issues/849

[2]: https://github.com/RustAudio/cpal/pull/337

[+] robrtsql|6 years ago|reply
Does this rely on the `.npmrc` file being cached from a previous run (which will only happen if you use a self-hosted runner)? Or does this vulnerability mean that PR contributors basically have direct access to all of the secrets that you put on your GitHub repo?
[+] tracker1|6 years ago|reply
absolutely... I think Github should probably put a warning statement on any PRs that include changes to .github/
[+] xPaw|6 years ago|reply
How would the workflow run if they specify `on: release: types: [published]`?
[+] pafo|6 years ago|reply
Thank you for this comment! It is a very good point.
[+] tracker1|6 years ago|reply
You don't need to write the environment variable to the .npmrc file... just setting the NODE_AUTH token and registry_url parameters. Here's mine...

https://gist.github.com/tracker1/fdd5ceab8f532afc3a05ab9c0bd...

[+] brianzelip|6 years ago|reply
Off topic, but cool, I didn't know npm has a version bump capability. I wrote my own small cli tool[0] for new releases, which could have been even smaller via leveraging the npm builtin. Thanks!

[0] https://github.com/brianzelip/bump

[+] koolba|6 years ago|reply
Alternatively don’t do anything like this and setup 2FA for your NPM account to prevent malicious publishes in the event of a compromise.

Another pleasant side effect is that 2FA prevents accidental publishes too.

[+] toomuchtodo|6 years ago|reply
Could something similar be used to publish an artifact to Pypi?
[+] ikornaselur|6 years ago|reply
I really like the idea of automating this whole process. While not generic to publishing to pypi, I was playing around with this process in a toy repo I have, where it builds a Rust/Python package, creates a release on Github if I bump the version number, build the package and publishes it on Pypi.

It probably not the cleanest way to do it, but I liked having it "spelled out" in steps manually to play around and learn more about how to do this.

You can see my workflow in the toy repo here: https://github.com/ikornaselur/img-utils/blob/master/.github...

[+] Latty|6 years ago|reply
I am actively doing this for a project of mine: https://github.com/Lattyware/unrpa

I also do a MyPy type check as well with the actions stuff. It's very similar to the GitLab CI stuff, if you have used that.

[+] k__|6 years ago|reply
Are GHAs like FaaS for Git?
[+] reilly3000|6 years ago|reply
Pretty much yes. Their build running machines are very powerful and loaded with lots of typical libraries. They specifically state that GHA should not be used as a general serverless compute platform in their TOS. I think that needs to be said because its perfectly capable of being a pretty robust FaaS platform in general- but certainly its totally valid to use as FaaS for git or anything that could be GitHub webhook, like PR comments, milestone updates, label creation, etc.