Hey, thanks for this, looks really useful. Just a feedback from a Codex security review which I think are worthwhile to address (but feel free to discard):
Verdict: I would not treat diffity as safe to install and run on a primary machine in its current state.
As of 2026-03-23, I reviewed the GitHub repo at commit 40ddc55 and the published npm package [email protected]. npm audit returned 0 known vulnerabilities for both the repo lockfile and the package resolved from npm, and I did not find obvious malware or credential-stealing behavior. The concern is the app’s own runtime security model.
-
High: the local web server exposes shell-injection paths. User-controlled ref, filePath, and commit search text flow from HTTP routes in packages/cli/src/server.ts, packages/cli/src/server.ts, and into shell-built commands in packages/git/src/diff.ts and packages/git/src/commits.ts. This is a real local RCE class issue, not just a code-quality concern.
-
High: the server is unauthenticated, sets wildcard CORS, and does not explicitly bind to loopback. See Access-Control-Allow-Origin: * in packages/cli/src/server.ts and the bare server.listen(currentPort) call. In practice, while diffity is running, a malicious website or possibly another host on the local network has a plausible path to hit those endpoints.
-
Medium: the published npm package is not reproducible. The package manifest declares several runtime dependencies as latest, including commander, open, and picocolors, in packages/cli/package.json. Today those resolved cleanly, but a future npm install -g diffity can pull different dependency code without a diffity version change.
-
Low: install-time execution is limited, but not zero. The main runtime install hook comes from better-sqlite3, which the package depends on via packages/cli/package.json. Its install script is prebuild-install || node-gyp rebuild --release, which is common for native modules, and I did not find known advisory hits in the resolved tree, but it still means install runs native build/download logic.
Bottom line: safe enough to inspect in a disposable VM/container, not safe enough that I’d recommend installing and running it normally on a workstation you care about.
Hey, thanks for this, looks really useful. Just a feedback from a Codex security review which I think are worthwhile to address (but feel free to discard):
Verdict: I would not treat
diffityas safe to install and run on a primary machine in its current state.As of 2026-03-23, I reviewed the GitHub repo at commit
40ddc55and the published npm package[email protected].npm auditreturned 0 known vulnerabilities for both the repo lockfile and the package resolved from npm, and I did not find obvious malware or credential-stealing behavior. The concern is the app’s own runtime security model.High: the local web server exposes shell-injection paths. User-controlled
ref,filePath, and commit search text flow from HTTP routes inpackages/cli/src/server.ts,packages/cli/src/server.ts, and into shell-built commands inpackages/git/src/diff.tsandpackages/git/src/commits.ts. This is a real local RCE class issue, not just a code-quality concern.High: the server is unauthenticated, sets wildcard CORS, and does not explicitly bind to loopback. See
Access-Control-Allow-Origin: *inpackages/cli/src/server.tsand the bareserver.listen(currentPort)call. In practice, whilediffityis running, a malicious website or possibly another host on the local network has a plausible path to hit those endpoints.Medium: the published npm package is not reproducible. The package manifest declares several runtime dependencies as
latest, includingcommander,open, andpicocolors, inpackages/cli/package.json. Today those resolved cleanly, but a futurenpm install -g diffitycan pull different dependency code without adiffityversion change.Low: install-time execution is limited, but not zero. The main runtime install hook comes from
better-sqlite3, which the package depends on viapackages/cli/package.json. Its install script isprebuild-install || node-gyp rebuild --release, which is common for native modules, and I did not find known advisory hits in the resolved tree, but it still means install runs native build/download logic.Bottom line: safe enough to inspect in a disposable VM/container, not safe enough that I’d recommend installing and running it normally on a workstation you care about.