Add a new linting rule to catch unsafe exec usage

[emily-shen]

Fixes n/a

Add a custom eslint rule that checks for unsafe command execution.

NB this PR was written with LLM help, i've reviewed and tested manually but I'm also not the most familiar with eslint plugins.

Also, not really related to this PR but I've added AGENTS.local.md to gitignore, hopefully that's okay.

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: internal

A picture of a cute animal (not mandatory, but encouraged)

[changeset-bot]

🦋 Changeset detected

Latest commit: 2e736b8

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@11902

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@11902

miniflare

npm i https://pkg.pr.new/miniflare@11902

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@11902

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@11902

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@11902

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@11902

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@11902

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@11902

wrangler

npm i https://pkg.pr.new/wrangler@11902

commit: 2e736b8

[petebacondarwin]

Love a PREVENTS - This looks good so not blocking but are we missing possible other scenarios such as aliased imports?

[petebacondarwin]

What about testing cases where the imports have been aliased?

E.g.

import { execSync as run } from "node:child_process";

[petebacondarwin]

And also namespaced imports?

import * as cp from "node:child_process";

[vicb]

Very nice!

Thanks @emily-shen

NB this PR was written with LLM help, i've reviewed and tested manually but I'm also not the most familiar with eslint plugins.

Agreed with that. It is a specific syntax that we don't really need to take time to deeply understand. Skimming through the rule file AND adding a test as you did is great.

[vicb]

question: what's the up of excluding those? execution time I guess? Does it make a huge difference? If not I would not exclude them for the reason I mentioned earlier offline: ideally there should be no vulnerable code anywhere to prevent avoid copy-pasting mistakes.

[emily-shen]

We have quite a lot of 'vulnerable' code in the tests, and i figured this was okay since we couldn't copy paste vulnerable code around by mistake without the linter complaining, since any non-test code is covered by the rule

[vicb]

Our beloved AI models (and developers before when they were still a thing) learn from that so it would definitely be better to fix but maybe not worth the effort.

If there is a common pattern that is mechanical to update, ASTGrep would be the best tool, we can discuss about that offline.