TavernKeeper Scan Report

doolijb/serene-pub

Commit d8587d7 Reviewed

No material or immediate-danger concern was identified in this review.

This advisory report describes what the named tools and review process found at one exact commit. Unknown or unobserved behavior may still exist.

0 immediate danger 0 material 56 low

What this review found

No material or immediate-danger item was identified.

Minor cautions

JavaScript analysis reported javascript.xray.unsafe-regex

Minor caution · medium confidence

A crafted input might briefly slow or freeze the local client, without showing broader security harm.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.

Contextual assessment: The expression may permit a local CPU slowdown, but this evidence shows no credential, persistence, code-execution, or cross-user impact.

Impact: low · Exploitability: plausible

Developer action: Bound the input length or replace the expression when practical.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.unsafe-regex
File role
tooling
Source
scripts/prune-dist.js:239
Deterministic technical evidence (36)
  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:206

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:107

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/docker.yml:66

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:352

  • JavaScript analysis reported javascript.xray.shady-link · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: src/lib/server/sockets/koboldcpp.allowedHost.test.ts:31

  • JavaScript analysis reported javascript.xray.shady-link · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: src/lib/server/koboldcpp/binaryManager.allowedHost.test.ts:39

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/docker.yml:69

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/docker.yml:22

  • zizmor reported template-injection · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:127

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:58

  • JavaScript analysis reported javascript.xray.serialize-environment · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-tooling · Execution scope: tooling-only

    Source: svelte.config.js:17

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:63

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:202-203

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/docker.yml:21-29

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:58

  • JavaScript analysis reported javascript.xray.data-exfiltration · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-tooling · Execution scope: tooling-only

    Source: scripts/check-db-lock.js:3

  • zizmor reported excessive-permissions · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:14-138

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/docker.yml:72

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:206

  • zizmor reported excessive-permissions · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:1-359

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/docker.yml:94

  • JavaScript analysis reported javascript.xray.unsafe-regex · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-unsafe-regex-inert · Execution scope: test-documentation-data

    Source: src/lib/shared/utils/docsIndex.test.ts:92

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:23-28

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:107

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:28-29

  • JavaScript analysis reported javascript.xray.shady-link · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: src/lib/shared/utils/normalizeBaseUrl.test.ts:6

  • JavaScript analysis reported javascript.xray.shady-link · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: src/lib/server/cardSources/githubYamlCardSource.test.ts:34

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/docker.yml:111

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:203

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:29

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:24

  • OpenGrep reported tavernkeeper.dynamic-execution.node-shell · opengrep 1.26.0

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: owned-inert-tooling · Execution scope: tooling-only

    Source: scripts/check-db-lock.js:232-235

  • JavaScript analysis reported javascript.xray.encoded-literal · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: src/lib/server/utils/uuid.test.ts:15

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:145

  • JavaScript analysis reported javascript.xray.shady-link · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-tooling · Execution scope: tooling-only

    Source: svelte.config.js:100

  • JavaScript analysis reported javascript.xray.serialize-environment · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-tooling · Execution scope: tooling-only

    Source: scripts/check-db-lock.js:29

Contextual expected matches (18)

JavaScript analysis reported javascript.xray.data-exfiltration

Expected behavior · high confidence

The file imports a standard system module to find the operating system temporary folder. This is used to create a throwaway directory for test data. No information is sent anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.data-exfiltration. The match applies to this repository.

Contextual assessment: Detailed technical wording was omitted by the public report safety filter.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.data-exfiltration
File role
production
Source
vitest.setup.ts:22

Credential access and network transmission in one file

Expected behavior · high confidence

The app asks its own server for a login token and uses that token to prove who you are when opening a live connection back to the same server. The token is only sent to the app itself, never anywhere else. This is the normal, expected way to set up authenticated real-time connections.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The file obtains a session token from a same-origin API endpoint that reads HttpOnly cookies server-side, then passes that token in the Socket.IO auth handshake for a connection made with no URL argument, which Socket.IO resolves to the same origin that served the page. This is a standard pattern for authenticating WebSocket connections when cookies are not otherwise forwarded, and the data flow stays entirely within the application's own server. There is no third-party destination, no storage of the token beyond the connection, and no disclosure outside the connection lifecycle; the same-file co-occurrence of the token source and network sink is inherent to establishing an authenticated socket, not evidence of exfiltration.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 5
Rule
credential-exfiltration
File role
production
Source
src/lib/client/sockets/loadSockets.client.ts:11

Credential access and network transmission in one file

Expected behavior · high confidence

This is the same authentication helper file flagged by a different scanner. It fetches the user's own login token from the app's server to enable real-time chat. The token is never sent anywhere except back to the app itself.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: Same file as the prior group, flagged by a separate scanner for credential source and network sink in one file. The fetch on line 11 targets the same-origin relative path /api/socket-token with credentials included, which is the standard pattern for retrieving the authenticated user's own socket token from the application backend. The cookie and localStorage reads in the same file are fallback token retrieval paths. No external destination is involved and no exfiltration path is demonstrated.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 5
Rule
credential-exfiltration
File role
production
Source
src/lib/client/auth.ts:11

OpenGrep reported tavernkeeper.dynamic-execution.node-shell

Expected behavior · high confidence

The script makes a macOS app launcher executable after creating it. This is a standard step in building app bundles and poses no security risk because no external input controls the command.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.node-shell. The match applies to this repository.

Contextual assessment: This candidate flags the execSync call at line 264, which runs chmod +x on the macOS app bundle executable script that was just written by fs.writeFileSync at line 261. The path is derived from path.join(macOSDir, 'serene-pub') where macOSDir is built from the script's own __dirname and hardcoded directory names. No untrusted input flows into the command. This is expected behavior for a packaging script that must set executable permissions on generated launcher scripts.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
opengrep 1.26.0
Rule
tavernkeeper.dynamic-execution.node-shell
File role
tooling
Source
scripts/create-executables.js:264

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

This module loads the app's configuration file early so the server picks up the operator's settings, and it fills in a few related settings automatically, then reports what it changed at startup. It reads config only to configure the server itself and never sends it anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.

Contextual assessment: The file runs dotenv at server startup and fills a small set of framework environment variables (reverse-proxy headers and origin) from operator-provided values, recording which derived keys it applied on a global so the startup banner can report them. Accessing process.env and writing derived values is the declared purpose of this preload module and is disclosed in comments and at startup. No environment contents are transmitted over a network, logged, or persisted outside the process, and only keys the operator already set influence the derivation. The scanner's serialize-environment heuristic matches the benign reading and writing of process.env entries, not an exposure path.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.serialize-environment
File role
production
Source
src/lib/server/config/preloadEnv.js:37

JavaScript analysis reported javascript.xray.unsafe-command

Expected behavior · high confidence

A scanner flagged a shell command in a build script. The command uses a fixed package name and a path computed from the script's own location, with no external or user-controlled input. This is a normal build-step utility, not a security issue.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-command. The match applies to this repository.

Contextual assessment: JS-X-Ray flagged the execSync call at lines 168-171 as an unsafe-command signal. The command string is constructed from nodeMobilePkg, which is a hardcoded string literal (nodejs-mobile-react-native@18.20.4), and tempDir, which is derived from the script's own filesystem location via path.join(rootDir, 'temp-nodejs-mobile'). No user input, external data, or untrusted content flows into the command. This is a build-time tooling script that fetches a specific npm tarball to extract native libraries for Android packaging, running in CI or local developer build contexts. The scanner confidence is low, and the actual data flow shows no injection path.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.unsafe-command
File role
tooling
Source
scripts/build-android.js:168-171

zizmor reported superfluous-actions

Expected behavior · high confidence

A code-quality scanner noted that this release-uploading action might duplicate something the runner already does. This is not a security problem. The workflow is well-structured with limited permissions and safe handling of tag names.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions. The match applies to this repository.

Contextual assessment: The zizmor superfluous-actions info finding flags the use of softprops/action-gh-release@v2 as potentially redundant with runner-included functionality. This is a code-quality hint, not a security vulnerability. The workflow properly narrows permissions to contents:write, passes REF_NAME through an environment variable rather than direct interpolation into run blocks, and uses secrets.GITHUB_TOKEN for release asset uploads. No attacker-controlled input reaches the release action; file paths come from a prior step output derived from a hardcoded version string and CI-produced build artifacts.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
superfluous-actions
File role
tooling
Source
.github/workflows/build-android.yml:145

JavaScript analysis reported javascript.credential-to-network

Expected behavior · high confidence

This file handles getting the user's own login token so they can connect to the app's real-time chat feature. It fetches the token from the app's own server and falls back to checking the browser's cookie or local storage. Nothing is sent to any outside service.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.credential-to-network. The match applies to this repository.

Contextual assessment: The scanner flags co-occurrence of credential-bearing state reads (document.cookie, localStorage) and an outbound fetch in the same file. The fetch targets a same-origin relative endpoint (/api/socket-token) to retrieve the user's own socket authentication token. The cookie and localStorage reads are fallback paths for the same auth token. All data flows remain within the application's own origin and serve the stated multi-user WebSocket authentication purpose. No credentials are transmitted to any external or third-party destination.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.credential-to-network
File role
production
Source
src/lib/client/auth.ts:11-36

JavaScript analysis reported javascript.xray.obfuscated-code

Expected behavior · high confidence

This is a build-time helper that edits the generated server file to add a decorative startup banner and automatically open the user's browser to the locally running app. The scary-looking block of symbols is just ASCII art for the banner, not hidden or encoded code. Nothing here sends data anywhere or hides what it does.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.obfuscated-code. The match applies to this repository.

Contextual assessment: The scanner flagged an obfuscation signal, but the supplied source is a plainly readable Node build script that reads a generated server file, applies documented regex replacements to brand startup messages, injects a startup banner, wires an env preload import, and enables a browser auto-open for a local address. The long runs of unusual characters that likely triggered the heuristic are decorative ASCII art inside string literals, not encoded or concealed payload. There is no data exfiltration, hidden execution, encoded indirection, or destination beyond the local build output; all destinations (localhost and 127.0.0.1) are disclosed and match the stated purpose of launching the packaged app.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.obfuscated-code
File role
tooling
Source
scripts/customize-build.js:1

zizmor reported superfluous-actions

Expected behavior · high confidence

A scanner suggested this release-upload action may be unnecessary. That is a style preference, not a security risk. The workflow safely handles credentials and tag names.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions. The match applies to this repository.

Contextual assessment: The zizmor superfluous-actions info finding targets the softprops/action-gh-release@v2 step in the release workflow. This is a quality suggestion, not a security issue. The job scopes permissions to contents:write, uses environment variables (REF_NAME) instead of direct interpolation to prevent script injection, and uses secrets.GITHUB_TOKEN for authenticated release uploads. File inputs are glob patterns matching CI-produced zip artifacts and step outputs from prerelease detection. No untrusted or attacker-controlled data flows into the action inputs in a way that creates concrete harm.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
superfluous-actions
File role
tooling
Source
.github/workflows/release.yml:352

Credential access and network transmission in one file

Expected behavior · high confidence

This file is the connector that sends chat prompts to the user's own KoboldCPP AI model server and receives responses. The scanner saw network calls in a file that also reads connection settings, but the network calls go only to the user's own configured AI server. This is exactly what the app is supposed to do.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: The scanner flags credential access and network transmission in one file. The credential-bearing state identified is this.connection.baseUrl, which is a user-configured KoboldCPP server URL, not a secret credential. The fetch calls target the user's own KoboldCPP instance to query context limits, send generation requests, and abort in-flight generations. All network destinations are derived from the user's own connection configuration. This is the core functionality of a KoboldCPP connection adapter in an AI roleplay application and matches the project's stated purpose of connecting to local or user-configured LLM backends. No credentials are exfiltrated to any third-party destination.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 5
Rule
credential-exfiltration
File role
production
Source
src/lib/server/connectionAdapters/KoboldCppAdapter.ts:116

JavaScript analysis reported javascript.xray.serialize-environment

Expected behavior · high confidence

The file checks two environment variables to decide where to put temporary test data, then sets one so tests use a throwaway folder instead of real data. No environment information is collected or sent anywhere.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.

Contextual assessment: The scanner flagged access to process.env as a serialize-environment signal. In the supplied source, process.env is read for two variables: SERENE_PUB_DATA_DIR and VITEST_WORKER_ID. One is then written with a temporary directory path. This is legitimate test infrastructure behavior that redirects test database operations away from real user data. No environment contents are serialized, transmitted, logged, or sent to any external destination. The signal is a false positive on standard test setup configuration.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.serialize-environment
File role
production
Source
vitest.setup.ts:25

OpenGrep reported tavernkeeper.dynamic-execution.node-shell

Expected behavior · high confidence

A scanner flagged a shell command in a build script. The command only uses a fixed package name and a locally-computed path, with no external input. This is a standard build utility action, not a security risk.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.node-shell. The match applies to this repository.

Contextual assessment: OpenGrep matched the execSync call at lines 169-172 for Node process execution. The command interpolates nodeMobilePkg (a hardcoded string constant) and tempDir (a path derived from the script's own directory). Neither value is attacker-controlled or sourced from untrusted input. The script runs as a build tool in CI or local build contexts. This is expected behavior for a build script that invokes npm pack to fetch a specific package tarball.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
opengrep 1.26.0
Rule
tavernkeeper.dynamic-execution.node-shell
File role
tooling
Source
scripts/build-android.js:169-172

OpenGrep reported tavernkeeper.dynamic-execution.node-shell

Expected behavior · high confidence

The script sets executable permissions on a Linux installer file it just created. This is a normal packaging step with no security concern.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.node-shell. The match applies to this repository.

Contextual assessment: This candidate flags the execSync call at line 180, which runs chmod +x on the Linux desktop-shortcut installer script that was just written at line 177. The path is constructed from path.join(platformDir, 'install-desktop-shortcut.sh') using internally-derived directory values. No external or user-controlled input reaches the command string. Making generated install scripts executable is expected behavior for a release packaging tool.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
opengrep 1.26.0
Rule
tavernkeeper.dynamic-execution.node-shell
File role
tooling
Source
scripts/create-executables.js:180

OpenGrep reported tavernkeeper.dynamic-execution.node-shell

Expected behavior · high confidence

The script makes a Linux app launcher executable after creating it. This is a routine build step with no external input involved.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.node-shell. The match applies to this repository.

Contextual assessment: This candidate flags the execSync call at line 201, which runs chmod +x on the Linux executable wrapper script just written at line 198. The path comes from path.join(platformDir, config.executable) where config.executable is the hardcoded string 'Serene Pub'. No untrusted input is involved. Setting executable permissions on a generated launcher is standard and expected for a cross-platform packaging script.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
opengrep 1.26.0
Rule
tavernkeeper.dynamic-execution.node-shell
File role
tooling
Source
scripts/create-executables.js:201

JavaScript analysis reported javascript.xray.obfuscated-code

Expected behavior · high confidence

This is a build helper that creates clickable app launchers for Windows, Linux, and macOS. The security scanner flagged it because a piece of generated Linux code contains complex escape characters that look suspicious to automated tools, but the code is actually straightforward and well-documented. There is nothing hidden or malicious here.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.obfuscated-code. The match applies to this repository.

Contextual assessment: The flagged file is a transparent Node.js packaging script that reads package.json, copies a favicon, and writes platform-specific launcher scripts (Windows .bat, Linux shell wrappers, macOS .app bundle). The obfuscation signal is a false positive, most likely triggered by the heavily-escaped sed expression embedded in the generated bash installer (line 153), which contains multiple backslash sequences for desktop-entry escaping. The surrounding code is readable, well-commented, and contains no encoded strings, eval, or hidden control flow. All file paths are derived from the script's own directory and hardcoded config values; no untrusted input is involved.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.obfuscated-code
File role
tooling
Source
scripts/create-executables.js:1

JavaScript analysis reported javascript.xray.unsafe-command

Expected behavior · high confidence

The build script runs a simple chmod command to make the launcher files it just created executable. This is normal and necessary for Linux and macOS app launchers. There is no way for outside input to influence what command runs.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-command. The match applies to this repository.

Contextual assessment: The three execSync calls (lines 180, 201, 264) each run chmod +x on files the script itself just created via fs.writeFileSync. The command arguments are constructed from path.join using the script's own __dirname, hardcoded platform directory names, and hardcoded config values (e.g., 'Serene Pub', 'serene-pub', 'install-desktop-shortcut.sh'). No user-controlled or external input reaches the command string. Running chmod on freshly generated shell scripts is expected and necessary behavior for a cross-platform packaging tool.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.unsafe-command
File role
tooling
Source
scripts/create-executables.js:179

OpenGrep reported tavernkeeper.dynamic-execution.node-shell

Expected behavior · high confidence

A scanner flagged a tar extraction command in a build script. The filename comes from a temp directory that the script itself just created and filled, not from external input. This is a normal build step, not a security issue.

Technical evidence

Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.node-shell. The match applies to this repository.

Contextual assessment: OpenGrep matched the second execSync call at lines 178-180, which runs tar extraction. The tarball filename is obtained from fs.readdirSync on a temp directory that was just created and populated solely by the preceding npm pack command. The tempDir path is derived from the script's own location. No external or attacker-controlled input reaches this command. The tarball content comes from the official npm registry for a pinned package version. This is expected build-time behavior in a tooling script.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
opengrep 1.26.0
Rule
tavernkeeper.dynamic-execution.node-shell
File role
tooling
Source
scripts/build-android.js:178-180

Related contextual observations

Test setup file uses local filesystem and environment access for isolation

low risk · high confidence

This is a test helper that makes sure tests do not accidentally touch real user data by creating a disposable folder for each test run. Everything it does stays on the local machine.

Technical assessment

The entire file is a Vitest setup script whose stated purpose is to redirect test database operations to a temporary directory. It uses node fs, os, and path modules to create and clean up that directory, and reads or writes two environment variables to coordinate the path. All operations are local, occur during test execution, and serve a defensive isolation purpose. No network, credential, or external data flow is present.

Impact: none · Exploitability: unlikely

Developer action: none

Sources:

Coverage and limitations

JavaScript coverage

Unresolved JavaScript stages

Tools

Limitations

Technical scan identity