You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "ggbdpq (via GitHub)" <gi...@apache.org> on 2026/09/27 00:19:39 UTC
[PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
ggbdpq opened a new pull request, #5744:
URL: https://github.com/apache/maka/pull/5744
Small hygiene fix for npm's install-scripts approval gate (npm ≥ 11.6): on a fresh clone of this repository, the gate flags **seven packages** whose install scripts are not covered by the `allowScripts` map in `package.json`.
- **Two entries trail the lockfile:** `esbuild@0.27.7` is allowlisted while the lockfile pins `0.28.2`, and `@jackwener/opencli@1.8.4` while the lockfile pins `1.8.7`. The exact-version keys no longer match what actually installs, so the gate still flags them.
- **Five packages were never allowlisted:** `electron-winstaller`, `protobufjs`, `tree-sitter-javascript`, `@astryxdesign/cli`, and `@astryxdesign/core` all carry install/postinstall scripts but had no entry at all.
Every allowlist entry is now the exact version pinned in `package-lock.json` (verified against `node_modules`), and a fresh `npm install` completes with no unreviewed-script warnings.
## Verification
| Check | Result |
| --- | --- |
| `npm install-scripts ls` after install | no unreviewed packages |
| `npm install` | 0 vulnerabilities, no gate warnings |
| A full `node_modules` scan for install/postinstall scripts | exactly the 8 allowlisted packages, all version-matched |
| `biome format package.json` | clean |
Devs on npm versions without the approval gate never see the warnings, which is why the list drifted.
## AI use
Implemented with GLM-5.3-Flash (ZCode): the lockfile cross-check, the allowlist refresh, and the completeness scan.
- [x] I have read the project's contributing guidelines
- [x] The commit message follows the repository convention
- [x] Every allowlist version is verified against `package-lock.json`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on PR #5744:
URL: https://github.com/apache/maka/pull/5744#issuecomment-5862169903
Addressed the P2 at `aa31461d4`: `"fsevents@2.3.3": true` sits in sorted position in the map. Confirmed against the lockfile (`node_modules/fsevents`: version 2.3.3, `hasInstallScript: true`, `optional`, `os: ["darwin"]`) — the entry allows its native build script, matching the treatment of `node-pty`/`esbuild`, so a fresh macOS install no longer trips the gate for it.
On the P3 (no guard against recurrence): agreed the map can drift again, but I'd keep this PR config-only and land the cross-check as a follow-up — a small script comparing `allowScripts` against the lockfile's `hasInstallScript` entries, wired into the existing `audit` job. Happy to open that follow-up PR with the check if you'd rather review it separately; say the word and it's coming.
The `opencli` `true -> false` flip stays as your non-issue note describes: its postinstall only wires shell completions and global-install adapter sync, and the desktop consumes it as a library.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on PR #5744:
URL: https://github.com/apache/maka/pull/5744#issuecomment-5882167687
Heads-up for reviewer bandwidth: #4865 (open since Sep 5, cross-referenced above) overlaps this PR on both halves — it refreshes the same stale `esbuild`/`@jackwener/opencli` pins and adds a guard at the **same path**, `scripts/check-allow-scripts.mjs`. The two guards differ in mechanism: #4865 delegates detection to `npm install-scripts prune --dry-run --json` (npm 11.19 semantics, pinned npm) and gates via `check:allow-scripts`; this PR's guard is a lockfile cross-check wired into the dependency-audit workflow (already green here, 6/6).
The allowlist-refresh half is duplicated labor — whichever PR merges first settles it. For the guard, #4865's npm-native semantics may be the better long-term replacement for this PR's lockfile cross-check; if the maintainers prefer that, I'm happy to rebase this PR's guard onto the prune-based approach or drop it in favor of #4865's — whichever avoids two competing scripts at the same path.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on PR #5744:
URL: https://github.com/apache/maka/pull/5744#issuecomment-5864933347
The test red on `0339c3ae4` is a single timing-sensitive assertion in `packages/runtime`'s `code-mode.test.js` ("excludes host waiting from the execution budget and preserves dependent Promise.race progress", `false !== true` at line 64) — nothing this PR touches, and the same file passes three consecutive local runs (33/33 each) on this exact tree. Head is now `a5b07c507`, a tree-identical retrigger.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on PR #5744:
URL: https://github.com/apache/maka/pull/5744#issuecomment-5903239309
Gentle ping — this has been quiet for a few days. Current head `f64e2fe88` merges current `main` with the existing deny decisions preserved and the three bumped package keys updated; the allowlist guard and its tests pass, all required checks are green, and the merge tree against current `main` is clean. Would appreciate a human review when there's a moment.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han merged PR #5744:
URL: https://github.com/apache/maka/pull/5744
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on PR #5744:
URL: https://github.com/apache/maka/pull/5744#issuecomment-5900423374
Conflict resolution pushed as `f64e2fe88`: the branch now integrates current `main` (through `8648258d0`, which includes the #5839 dependency upgrades — `upstream/main` advanced once more mid-resolution, merge message records the exact tip).
Since this PR's whole subject is the lockfile cross-check, I re-validated the allowScripts map against the **new** lockfile rather than just resolving the textual conflict:
- `@astryxdesign/cli` 0.6.2 → **0.6.3**, `@astryxdesign/core` 0.6.2 → **0.6.3**, `@jackwener/opencli` 1.8.7 → **1.8.8**: keys re-pinned; values unchanged (`false` — the deny rationale is version-independent for these).
- `opencli@1.8.8` stays **denied** even though the merge brings in main's `overrides` entry referencing it: main's `true` is a mechanical carry-over from the batch bump, while this PR's `false` is the reviewed decision (its postinstall only installs shell completions; nothing Maka consumes).
- The other 6 entries match the new lockfile verbatim (no version drift). Lockfile still reports exactly 9 `hasInstallScript` packages — zero additions, zero removals.
- `scripts/check-allow-scripts.mjs` passes on the resolved tree (`allowScripts covers all 9 install-script packages with exact name@version keys`), its test file passes 4/4.
Delta against `upstream/main` is still exactly the PR's 4 files. One honest limitation, unchanged from the PR body: the actual install-script executions (notably `fsevents`, Darwin-only) can't be exercised on this Windows machine — key-level verification only, CI covers the rest.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on PR #5744:
URL: https://github.com/apache/maka/pull/5744#issuecomment-5862701198
Both review threads are now closed on head `c43d3b077`:
- **P2 (fsevents missing):** addressed at `aa31461d4` — `"fsevents@2.3.3": true` sits in sorted position in the map, verified against the lockfile entry (`optional: true`, `os: ["darwin"]`, `hasInstallScript: true`).
- **P3 (no drift guard):** implemented at `c43d3b077`. `scripts/check-allow-scripts.mjs` fails on any lockfile entry carrying `hasInstallScript` that the map does not key (optionality is not an exemption — the fsevents case), any map key trailing the lockfile (this PR's root cause), and any non-boolean decision. `dependency-audit.yml` runs it beside the shipped-closure audit and its paths filter now covers the script. The script's own test covers the synced map, the fsevents case, the stale-version bump, and a non-boolean value (4/4 green locally), and the audit job on this head already passed with the step in place.
The `test` failure on the earlier head `aa31461d4` was not from this PR either: it is the `main`-preexisting `acp-goal-plan-child-process.test.js` timeout, now filed as #5777 (red starts at `0fd754083`, parent `ca1ac87ca` green; #5265 hits the identical signature).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] chore: refresh the install-scripts allowlist against the lockfile [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on PR #5744:
URL: https://github.com/apache/maka/pull/5744#issuecomment-6059912339
Gentle ping — no review signal since Sep 29. For context on the head move: `f64e2fe88` merges current `main` (including the #5839 dependency upgrades) and resolves the `allowScripts` conflict by keeping the existing deny decisions while updating the three bumped keys (`@astryxdesign/cli`/`@astryxdesign/core` 0.6.3, `@jackwener/opencli` 1.8.8); that merge increment was covered by the Sep 29 review with no new findings, and all checks (`test`, `audit`, `package`, `package-linux`, both owner jobs) are green. Could you take another look when you have a moment? Thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org