No material or immediate-danger item was identified.
zizmor reported excessive-permissions
Minor caution · high confidence
The CI workflow does not spell out what permissions it needs. In practice GitHub gives it only read access for pull requests, which is all this workflow uses, so there is no real danger—just a missing best-practice line.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The workflow has no explicit permissions block. For pull_request events from forks, GitHub defaults to read-only token permissions, and this workflow only checks out code and runs local node scripts without needing write access. The absence of an explicit permissions declaration is a best-practice gap, not an exploitable over-grant in this context.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block with contents: read to the job or workflow.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/ci.yml:9-26
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version label for a build tool instead of locking it to an exact code snapshot. If that label were ever hijacked, the CI could run altered code, but this is a low-probability event for official GitHub-provided tools.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The setup-node action is pinned to the v4 major-version tag rather than a full commit SHA. This is widespread practice for first-party GitHub actions, but SHA pinning is the recommended hardening against tag-retag supply-chain attacks. The workflow runs on pull requests, so a compromised action could execute in CI context, but the blast radius is limited to the CI runner with read-only token scope.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/setup-node to a full commit SHA for supply-chain hardening.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:13
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version label for the code-checkout tool instead of an exact snapshot. This is a minor hardening gap with low real-world risk for an official GitHub action.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The checkout action is pinned to the v4 major-version tag rather than a full commit SHA. Same supply-chain consideration as the setup-node step. The workflow does not upload artifacts or expose secrets beyond the default read-only token, limiting impact.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/checkout to a full commit SHA for supply-chain hardening.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:12
Expected scanner matches (20)
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is part of a built-in test script that pulls a function out of the extension's own code to verify it works correctly. It only runs code that already ships with the project, not anything from outside.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This candidate is a `new Function` call inside a self-check test harness. It extracts the shipped `mergeChainSummary` function body from the extension source by string slicing and instantiates it to run assertions. The code passed to `new Function` originates entirely from the project's own committed extension source read locally; no external, network, or user-controlled input reaches it. This is a standard test-isolation pattern.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:904
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test script that pulls a specific function out of the extension's own code file and runs it against fake test data to make sure the settings-migration logic works correctly. The code being executed comes from the project itself, not from anything external or user-provided, and the test inputs are invented on the spot. This is a normal way to test code that isn't separately exported.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The flagged `new Function` at line 447 is inside a self-check test file. It constructs a function from `_ADOPT_SRC`, which is a substring sliced from the project's own shipped `extension.js` source (read locally via `readFileSync`). The regex-extracted namespace and suffix constants, plus a fake in-memory localStorage object, are the only arguments. No external or user-controlled data reaches the function body or its arguments. The purpose, as documented in surrounding comments, is to test the actual shipped `adoptLegacyNamespace` migration logic against synthetic localStorage states rather than a hand-maintained mirror. There is no network call, credential access, persistence, or obfuscation. The dynamic execution is proportionate to the stated testing purpose and operates solely on locally-derived project code.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:447
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test script loads the extension's own patching function with fake dependencies to check how it handles bad server responses. No outside data is involved.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A `new Function` call in the self-check harness that instantiates the shipped `guardedPatch` with stubbed dependencies to test non-array re-read handling. The function body is sliced from the project's own extension source; no untrusted input flows into the dynamic execution.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1034-1037
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that runs the extension's own code in a sandboxed way to verify it behaves correctly. The code being run comes from the extension itself, not from any external source, and all the pieces it interacts with are fake stand-ins created by the test. This is a normal testing approach, not a security risk.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This candidate is a `new Function` call inside a self-check test harness. The code being executed is extracted from the project's own extension source via string slicing of `_SRC` (read from `extension.js`). All arguments passed to the constructed function are locally created stubs (mock DOM elements, stubbed `guardedPatch`, mock history/redo arrays). No untrusted or external input flows into the dynamic execution. This is a standard pattern for testing shipped code in isolation with controlled dependencies.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1222-1226
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test script loads the extension's own undo and redo functions with fake dependencies to verify their behavior. Only the project's own code is executed.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A `new Function` call that extracts and instantiates the shipped `doUndo` and `doRedo` functions with stubbed guard, history, and UI dependencies for unit testing. The source string comes from the project's own committed extension code read locally.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1055-1058
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test file extracts the extension's own text-matching helper functions and runs them against made-up test data to make sure they work correctly. Nothing from outside the project is involved, so there is no security concern.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This `new Function` call constructs a test harness for the extension's fingerprint helper functions (`nthIndexOf`, `ctxFingerprint`, `fingerprintOk`). The source string is extracted from the project's own `extension.js` via `_SRC.slice(...)`. No external input is passed; the function is invoked with no arguments and returns the extracted helper functions for testing against hardcoded test strings. This is a self-contained unit test pattern.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1166-1167
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that pulls out pieces of the extension's own code and runs them in isolation to make sure they work correctly. The code being run is the extension's own source, not anything from the user or the internet, so there is no security risk.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This candidate is a `new Function` call inside a self-check harness. The code being dynamically executed is extracted from the project's own shipped extension source (`_SRC`) — specifically the `splitToSize`, `windowText`, and `assembleLedgerText` functions. The extracted source is then invoked to verify byte-identical round-trip behavior of the ledger pattern. No external or user-controlled input reaches the `new Function` constructor; the string is a slice of the project's own committed code. This is a legitimate test-time technique for isolating and exercising internal functions outside the browser runtime.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1442-1444
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test script pulls the extension's own text-escaping function out of its source code to verify it blocks prompt-injection attempts. No outside code is run.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A `new Function` call that extracts the shipped `escFence` helper from the extension source and returns it for fence-escaping assertions. The dynamically executed code is a verbatim slice of the project's own committed source; no external input is involved.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:736
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test file runs the extension's own AI-request function with fake network connections to verify it handles errors and sends requests correctly. The code being tested is the extension's own, and the network calls are fake. This is normal testing, not a security issue.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This `new Function` call tests the extension's `runInference` function by extracting it from the project's own source and passing in stubbed dependencies: a mock `marinara` object with a stubbed `apiFetch`, a no-op `logDbg`, a `fetch` that throws, and an empty `Headers` class. The test verifies that the inference function correctly refuses without a connection, posts to the right endpoint with the right body, and surfaces errors properly. No untrusted input reaches the dynamic execution; all inputs are controlled test fixtures.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1295-1298
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test file runs the extension's own review-and-apply feature with fake on-screen elements to make sure it works correctly before changes are saved. Everything is simulated within the test, so there is no security risk.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This `new Function` call tests the extension's `reviewThenPatch` function by extracting it from the project's own source and passing in stubbed DOM builder functions, a stubbed `guardedPatch`, mock history/redo arrays, and mock toast/error handlers. The test simulates clicking an Apply button on a fake modal to verify the review-apply flow routes through the guard correctly. All inputs are locally created test fixtures; no untrusted data is involved.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1120-1123
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a local test script that runs part of the extension's own code to verify it works correctly. The code being executed comes from the project's own files, not from anything a user or attacker could control.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A new Function constructor is used inside a self-check harness to extract and execute a slice of the extension's own header-building logic read from the local source file. The argument to new Function is derived entirely from the project's own committed source, not from external or user-controlled input. This pattern exists to test the shipped behavior of the apiFetch header logic rather than relying on text pattern matching.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:116
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test script loads the extension's own merge functions with a fake commit handler to check that partial failures are reported correctly. Only project code is executed.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A `new Function` call that instantiates the shipped `applyMerged` and `mergeChainSummary` functions with a stubbed `doCommit` to test merge-chain partial-failure aggregation. The function body is extracted from the project's own extension source; no untrusted data reaches the dynamic execution boundary.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:835-838
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test script loads the extension's own overwrite-protection function with fake dependencies to verify it prevents silent overwrites. No outside code is involved.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A `new Function` call that instantiates the shipped `guardedPatch` with stubbed cache, confirm, and patch dependencies to test concurrent-edit overwrite protection. The source string is a slice of the project's own committed extension code; no external or user-controlled input flows in.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:949-952
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test script pulls the extension's own budget-trimming function out of its source code to verify it keeps prompts within size limits. Only project code is run.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A `new Function` call that extracts and instantiates the shipped `trimContextToBudget` and `PROMPT_BUDGET` constants from the extension source to test prompt-budget trimming logic. The dynamically executed code is a verbatim slice of the project's own committed source read locally.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:771-774
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is part of the same local test script. It pulls specific text-processing functions out of the extension's own code so it can verify they behave correctly against test inputs. Nothing from outside the project feeds into this execution.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A new Function constructor is used in the self-check harness to extract and execute span-alignment functions from the extension's own source file. The function body is composed from slices of the locally read extension source plus a return statement that exposes named functions. No external or network-derived data flows into the constructor. This is a test-only mechanism to run the actual shipped functions against fixed test cases.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:174-178
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test file that reads the extension's own code, extracts a piece of it, and runs that piece in an isolated wrapper to check that bad data does not crash the extension. The code being executed is the extension's own source, not anything from the user or the internet. This is a normal way to test code in isolation.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This candidate is a new Function call inside a self-check file. The function body is assembled from source code extracted from the extension's own source file via readFileSync and string slicing, not from user input or network data. The constructed function is immediately invoked with a hardcoded test string to verify that malformed legacy profile data does not throw. This is a standard isolation testing pattern where extracted production code is executed in a sandboxed scope alongside test scaffolding so assertions can validate behavior. No untrusted or external data reaches the dynamic execution path.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:632-640
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is another test in the same self-check file. It extracts the extension's import-handling code and runs it in an isolated wrapper with a fixed test list to confirm that duplicate profile IDs are handled correctly. The executed code comes from the extension itself, not from any external or user source, so there is no security concern.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: Detailed technical wording was omitted by the public report safety filter.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:603-608
zizmor reported artipacked
Expected behavior · high confidence
This finding is about secrets leaking through saved build artifacts. The workflow never saves any artifacts, so there is nothing for a secret to leak through.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked pattern concerns credential persistence when workflow artifacts include the .git directory with an embedded token. This workflow never uploads artifacts; it only runs local node scripts and a git diff check. The checkout default persists a token in .git/config on the runner, but without artifact upload there is no exfiltration path.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/ci.yml:12
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
The test script loads the extension's own patching function with a fake failing read to confirm it refuses to write when it cannot verify the current state. No outside code is executed.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A `new Function` call that instantiates the shipped `guardedPatch` with a stubbed `cachedMessages` that rejects, to verify a failed re-read does not fall through to a blind write. The function body is extracted from the project's own extension source; no untrusted input is involved.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1012-1015
OpenGrep reported tavernkeeper.dynamic-execution.javascript-eval
Expected behavior · high confidence
This is a test that takes the extension's own configuration-loading code and runs it with controlled test inputs to verify that old settings get migrated correctly. The code being executed comes from the extension itself, not from any external or user source, so there is no security risk.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: This candidate is a `new Function` call inside the same self-check harness. The dynamically constructed function body is `_CFG_SRC`, a substring extracted from the project's own shipped extension source (`_SRC`) corresponding to the config-loader IIFE. The function is invoked with controlled test arguments (`stored`, `k`, `DEF`) to verify config-migration logic. No external or user-controlled data flows into the function body; only the project's own committed code is executed. This is a standard pattern for testing extracted code in isolation.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.javascript-eval
- File role
- production
- Source
- selfcheck.mjs:1392