memcache - chore: defense - block pnpm lifecycle scripts - #109
Conversation
Fail closed unless a package is on the allowBuilds list. Keep esbuild and workerd as reviewed native-binary exceptions. Reconcile the 7-day cooldown as merged in PR #108. Co-authored-by: Jared Wray <me@jaredwray.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #109 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 8 8
Lines 1399 1399
Branches 303 308 +5
=========================================
Hits 1399 1399 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Co-authored-by: Jared Wray <me@jaredwray.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a02edf150e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| This repository follows the [defense-in-depth](https://github.com/jaredwray/agentic/blob/main/skills/security/defense-in-depth-nodejs/SKILL.md) hardening checklist; progress is tracked in [DEFENSE_IN_DEPTH.md](./DEFENSE_IN_DEPTH.md). Measures currently in place: | ||
|
|
||
| - Codespaces and Cursor Cloud Agents install through Aikido Safe Chain; package-manager shims must not be bypassed. | ||
| - Dependencies install through pnpm with a 7-day cooldown on new versions, and lifecycle scripts are blocked by default. Socket reviews every dependency change; Aikido scans every build. |
There was a problem hiding this comment.
Remove unimplemented scanning claims
This states that Socket reviews every dependency change and Aikido scans every build, but the inspected test, coverage, release, and deploy workflows all run pnpm install directly without SocketDev/action, sfw, or Safe Chain; DEFENSE_IN_DEPTH.md line 31 also still marks Socket Firewall as pending. Safe Chain is only bootstrapped for the cloud-agent environments, so this security policy currently promises controls that do not cover CI builds or every dependency change.
AGENTS.md reference: AGENTS.md:L52-L52
Useful? React with 👍 / 👎.
| @@ -1,3 +1,6 @@ | |||
| strictDepBuilds: true | |||
There was a problem hiding this comment.
Classify the macOS fsevents build before failing closed
On macOS, the locked optional fsevents@2.3.3 dependency is installed and has a node-gyp rebuild install script, but it is absent from allowBuilds. The pnpm setting documentation says that strictDepBuilds makes installation fail when a dependency's build scripts are not explicitly allowed; consequently, a clean macOS pnpm install exits with ERR_PNPM_IGNORED_BUILDS before build or tests run. Add a reviewed fsevents: true or fsevents: false classification so this policy does not break installs on Darwin.
Useful? React with 👍 / 👎.
* chore: defense - block exotic pnpm subdependencies Reject git/file/link/tarball subdependencies so the tree can only come from the registry. Reconcile lifecycle-script blocking as merged in PR #109. Co-authored-by: Jared Wray <me@jaredwray.com> * chore: defense - record PR #110 on blockExoticSubdeps checklist Co-authored-by: Jared Wray <me@jaredwray.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Summary
Block dependency lifecycle scripts by default, so only reviewed
allowBuildsexceptions may run install/build scripts.Status update
DEFENSE_IN_DEPTH.md: § 3 lifecycle scripts → (PR #109 pending); 7-day cooldown → PR #108 (merged)Changes
pnpm-workspace.yaml:strictDepBuilds: true,dangerouslyAllowAllBuilds: falseesbuildandworkerdonallowBuilds(native binaries via postinstall; empty baseline otherwise)SECURITY.mdVerification
pnpm install --frozen-lockfilepnpm buildReference
defense-in-depth-nodejs § 3