Install verification: runtime verified (L5) · tested on dsh 0.2.1-rc.2 · last checked Install verification details →
What it does
一级菜单旁添加可供插件接入的“功能”菜单栏,可以快捷添加插件功能,也可以自定义插件功能置入。v0.4.0 现已集成“重启dsh”功能
Installation
dsh plugin --profile web add github:Num86/dsh-functionsInstall 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 | dsh 0.2.1-alpha.4 |
|---|---|---|
| 88032d | ✓ | ✓ |
88032dgithub✓ 2 runtime-verified2026-10-19
https://github.com/Num86/dsh-functions
✓dsh 0.2.1-rc.2current2026-10-19L5 · runtime verified
- • Node.js: v24.14.0
- • DSH: 0.2.1-rc.2
- • Plugin artifact: github · https://github.com/Num86/dsh-functions (version unstated)
ID: dsh-functions@88032d@dsh0.2.1-rc.2 · profile: l4-sandbox
Issued: 2026-10-19 · expires: 2026-10-26
View checks & evidence
active in loader tree (151 entries)
L1–L3 are plugin-level static conclusions (baseline, identical across dsh versions): evidence is stored once per plugin.
✓dsh 0.2.1-alpha.42026-10-18L5 · runtime verified
- • Node.js: v24.14.0
- • DSH: 0.2.1-alpha.4
- • Plugin artifact: github · https://github.com/Num86/dsh-functions (version unstated)
ID: dsh-functions@88032d@dsh0.2.1-alpha.4 · 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-functions/)``[](https://www.dsh.so/artifact/dsh-functions/)`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.4.1dsh manifest0.4.1git2026-10-210.4.1same versionclean · gitVet is an AST static scan (npm artifact or git source).
show static findings (5)
- warningchildProcess · code-exec
index.js:142child = spawn(command, args, { - warningchildProcess · code-exec
restart-helper.js:96spawnSync(executable, ['/PID', String(pid)], { stdio: 'ignore', windowsHide: true }); - warningchildProcess · code-exec
restart-helper.js:108const result = spawnSync(executable, ['/PID', String(pid), '/T', '/F'], { stdio: 'ignore', windowsHide: true }); - warningchildProcess · code-exec
restart-helper.js:121result = spawnSync(executable, ['/NH', '/FO', 'CSV', '/FI', 'PID eq ' + String(pid)], { - warningchildProcess · code-exec
restart.js:326const outer = spawn(process.execPath, [HELPER_PATH, '--outer', JSON.stringify(payload)], {
show 2 audit findings
- medium/api/dshFunctions/run treats a client-supplied confirm:"yes" as user consent, so the confirmation dialog can be bypassed
index.js:522The two-stage prepare/confirm flow exists only in client.js; the host accepts any POST containing confirm:'yes'. Any script running in the DSH page (another third-party client plugin, or an XSS) can therefore invoke every registered host function with no dialog — including shell functions declared in profile config (arbitrary configured process spawn) and the restart action that force-kills and relaunches the app. If the host's fetch routes perform no origin/CSRF check, a cross-site form POST with a text/plain body that parses as JSON would also reach the handler, since Request.json() does not
- low'load functions' injects a fixed instruction as a role:'user' message into any caller-supplied session id
index.js:398The /run handler forwards body.sessionId verbatim into the function context, and this loader posts the ~5KB LOAD_INSTRUCTION into whatever session that id names, marked with source kind 'user' so it is indistinguishable from a real user message. Combined with the confirmation bypass above, a page-level actor can make an agent the user is not watching enumerate the profile directory, read package.json/READMEs into the transcript, and (after a reply) install or modify plugin files — without the user having clicked the action.
Host action registry whose /run gate is only a client-supplied confirm:"yes", letting any page script or CSRF-capable request fire configured shell/restart actions without the dialog.
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-19 · activity: Active
• Repo created: 2026-10-16
• Stars: ★ 0 · Forks: 0
• Health: Active — committed within last 30 days
Source
GitHub: github.com/Num86/dsh-functions
Author README
View on GitHub ↗The author's original README from the repository — fetched live, unedited (the English page loads the default README).
