Updated my security checklist with a few additions from yesterday’s Tanstack compromise: www.zachleat.com/web/npm-secu...
Zach Leatherman 77 replies 3131 likes77 reposts Original on MastodonOriginal on BlueskyAlso posted to Mastodon.
7 replies
pull_request_target is fine if you're not checking-out any code from the branch, which is the default. e.g. I have one that checks if they've used the PR template
I do think it’s time to classify it as a foot gun!
Oh definitely a foot gun. My point is that it's not necessarily a red flag, as it can be used safely and there are many tasks that can only be done that way.
ah, sure. Are you taking issue with the language I used in the post? On re-read it still matches what I want to say given that to fix the Tanstack bundle-size.yml action they swapped to from `pull_request_target` to `pull_request`
@zachleat small addition to `npm install`'s cooldown feature:
there's also a `--min-release-age X` flag (https://docs.npmjs.com/cli/v11/commands/npm-install#min-release-age) which acts similarly as the one in `pnpm` / `npm-check-updates`, delays packages to be at least X days old.the `npm update` command also has this flag, and you can even put a `min-release-age` into your (or project's) `.npmrc`, or set via `export npm_config_min_release_age=X` in `.zshrc`!
(this info is courtesy of @stefan's web weekly newsletter from this week)
@zachleat @stefan fun fact #2, the env var takes precedence above all other config:
```
$ sudo npm config set --location=global min-release-age=365
$ npm config set --location=user min-release-age=730
$ npm config set --location=project min-release-age=1095
$ export npm_config_min_release_age=1460
```calling `npm config list` would show a date in 2025, overriden by 2024, overriden by 2023, overriden one last time by 2022.
but it's not the largest value, having `1` value would show yesterday!