Install verification: runtime verified (L5) · tested on dsh 0.2.1-rc.2 · last checked Install verification details →
What it does
DSH dashboard plugin: 看板 tab with widget grid — LLM usage/nodes, local macOS probes, service health, optional Glances/Uptime Kuma, feed digest cards (Markdown-rendered)
Installation
dsh plugin --profile web add github:LosEcher/dsh-dashboardsInstall method: GitHub · runtime verified (L5)
Verification & Compatibility
Grouped by plugin version: each card lists the dsh versions actually tested against that artifact version and their install verdicts (L5 wins). Untested combinations are omitted — absence means untested, never assumed compatible. L1–L3 are a plugin-level static archive (independent of the dsh version — the same verdict on every dsh row): they sit in each row's level grid next to L4/L5, marked "static", while their evidence is stored once per plugin inside that row's "checks & evidence" instead of being duplicated per version.
External credentials (plugin-level): none detected
○ The author declares no dsh version requirement — install is not blocked by version.
| plugin ＼ dsh | dsh 0.2.1-rc.2 current |
|---|---|
| 7200e1 | ✓ |
7200e1github✓ 1 runtime-verified2026-10-18
https://github.com/LosEcher/dsh-dashboards
✓dsh 0.2.1-rc.2current2026-10-18L5 · runtime verified
- • Node.js: v24.14.0
- • DSH: 0.2.1-rc.2
- • Plugin artifact: github · https://github.com/LosEcher/dsh-dashboards (version unstated)
ID: dsh-dashboards@7200e1@dsh0.2.1-rc.2 · profile: l4-sandbox
Issued: 2026-10-18 · expires: 2026-10-25
View checks & evidence
active in loader tree (150 entries)
L1–L3 are plugin-level static conclusions (baseline, identical across dsh versions): evidence is stored once per plugin.
Author badges
Embed the official badges in your README to showcase security & install-test status:
`[](https://www.dsh.so/artifact/dsh-dashboards/)``[](https://www.dsh.so/artifact/dsh-dashboards/)`Security Report
Two automated layers, neither a manual review: a static scan (per-plugin rule checks) and a model-driven dynamic security audit that covers only the subset static-flagged at warn or above and never executes plugin code.
Static low, dynamic medium — stricter wins → overall medium.
v0.1.0dsh manifest0.1.0git2026-10-21ea76e75fcfa6version moved onclean · gitVet is an AST static scan (npm artifact or git source).
show static findings (1)
- warningnetIp · network
scripts/observe-guardrails.mjs:33const BASE = process.env.DSH_DASH_BASE ?? 'http://127.0.0.1:3080'
show 4 audit findings
- mediumDocumented egress kill-switch Config.egress.z4pro is never checked, so NAS polling keeps running when disabled
index.mjsresolveConfig defines egress.z4pro and the schema comment promises '任一置 false 即彻底不外呼（GET /dashboards/egress 可核对当前生效值）', and egressInventory lists it, but collectZ4Pro only tests z4pro.enabled. With Config.egress.z4pro=false the plugin still runs `bash -c 'node "$0" --json ...'` every 120s, which SSHes to the configured NAS and runs smartctl/virsh — an operator-visible egress control that silently does not apply to one channel while /dashboards/egress claims it does.
- lowPUT /dashboards/probe-targets accepts any URL or host:port, and the host then issues the requests
index.mjssanitizeTarget applies no scheme or host allowlist, and collectProbe later calls `fetch(target.url, { method: 'HEAD' })` and `createConnection({ host, port: target.port })`, returning status/error code and latency. Any client that can reach the loopback DSH webserver (any local process) can therefore repoint the probes at internal addresses (e.g. 169.254.169.254, RFC1918 hosts, arbitrary ports) and use the dashboard as a limited SSRF/port-scanner. Exposure is bounded: responses expose only HTTP status/errno, the listener is loopback-only, and no CORS headers are set so a web page cannot issue
- lowJSON body reader buffers the request without any size or time limit
index.mjsBoth PUT handlers (/dashboards/widgets and /dashboards/probe-targets) accumulate the entire request body in memory with no cap; a local (or, if the webserver is ever proxied, remote) client can stream a large body and exhaust the DSH web server heap, taking down the dashboard route and the co-hosted DSH UI.
- lowAuto-refresh mutates ~/.grok/auth.json and sends the stored refresh_token to auth.x.ai by default
index.mjsThe plugin rewrites a credential file owned by another tool (the Grok CLI) and POSTs the stored refresh_token to https://auth.x.ai/oauth2/token whenever the access token is within one hour of expiry (autoRefreshGrok defaults to true). The token is not logged and the temp file is 0600, but the plugin takes ownership of a foreign login store: a concurrent Grok CLI write or a future auth.json layout change can corrupt the login, and the write is only gated by Config.aiQuota.autoRefreshGrok / Config.egress.grokRefresh.
Local read-only dashboard API with credential-bearing outbound calls; one medium finding (z4pro egress kill-switch never enforced) plus low SSRF/DoS/credential-file issues.
Rule: the dynamic audit can only raise risk, never lower it (raise-only, never an exemption); a wrong raise is withdrawn by human review and the tier falls back to the static verdict. Overall verdict = the stricter of the two layers.
Disclaimer: the static scan and the dynamic security audit are both automated analysis, not a security guarantee. Always review what you install.
Activity
Last commit 2026-10-21 · activity: Active
• Repo created: 2026-08-17
• Stars: ★ 0 · Forks: 0
• Health: Active — committed within last 30 days
Source
Author README
View on GitHub ↗The author's original README from the repository — fetched live, unedited (the English page loads the default README).