openclaw/clawhub
1
0
Fork 0
mirror of https://github.com/openclaw/clawhub.git synced 2026-07-21 19:25:25 -04:00
Code Issues 183 Packages Projects Releases 1 Wiki Activity

[ SECURITY SCAN ] Make the VT analysis pipeline better and use tiered labels in Clawhub #98

New Issue
Open
opened 2026-02-15 17:15:39 -05:00 by yindo · 0 comments
yindo commented 2026-02-15 17:15:39 -05:00
Owner
Copy Link
Copy Source

Originally created by @therohitdas on GitHub (Feb 8, 2026).

I'm the author of youtube-full and slack-personal. Both got flagged as "Suspicious" by VT Code Insight. After reading the analysis carefully, I realized something: the analysis engine is genuinely good. It accurately understands what my code does. The problem is everything that happens after comprehension — classification, output format, and missing context about the OpenClaw ecosystem.

This issue covers multiple improvement areas that are all connected. They're all about the same thing: making the VT analysis output match the quality of its comprehension.

1. The analysis is accurate but the verdict contradicts its own findings

youtube-full (v1.3.2)

Image

Type: OpenClaw Skill Name: youtube-full Version: 1.3.2 The skill is classified as suspicious due to its high-privilege setup process. The SKILL.md instructs the AI agent to handle sensitive user credentials (email, password, OTP) and temporarily 'SAVE THE PASSWORD' for a multi-step authentication flow. The scripts/tapi-auth.js script, specifically the cmdSaveKey function, then writes the obtained API key to numerous system-wide configuration files, including agent configuration (~/.clawdbot/moltbot.json, ~/.openclaw/openclaw.json), various shell RC files (~/.zshenv, ~/.profile, ~/.bashrc, ~/.zprofile, ~/.config/fish/config.fish, PowerShell profile), and systemd user environment files. While these actions are explicitly for configuring the TRANSCRIPT_API_KEY for the stated purpose of the skill and all network communication is with the legitimate transcriptapi.com domain, the broad capability to modify multiple critical system configuration files and the instruction for the agent to manage plain-text passwords during setup represent significant security risks if the script were compromised or the agent's instructions were misinterpreted, even without clear evidence of intentional malicious exfiltration or arbitrary code injection in the current version.

The analysis correctly identifies:

✅ All file modifications (~/.bashrc, ~/.zshenv, ~/.openclaw/openclaw.json, etc.)
✅ The credential flow (email → OTP → API key)
✅ Network destination (transcriptapi.com — matches declared homepage)
✅ Purpose ("explicitly for configuring the TRANSCRIPT_API_KEY for the stated purpose of the skill")
✅ No malicious intent ("no clear evidence of intentional malicious exfiltration or arbitrary code injection")

Then classifies it as: Suspicious.
The analysis acquits the skill in the same paragraph it convicts it.
I think the classification in this case is totally wrong. Even "caution" does not do justice to this one.
It is a clean and seamless skill that does the heavy-lifting by giving a deterministic script to the Agent to do the one-time setup. I think we should find ways to standardize these practices instead of penalizing it with a LABEL

slack-personal (v0.1.6)

Image

Type: OpenClaw Skill Name: slack-personal Version: 0.1.6 The skill is classified as suspicious due to its use of high-risk capabilities to extract sensitive Slack session credentials. The src/auth.js file utilizes child_process.execSync and child_process.spawnSync to run system commands (security, sqlite3, openssl, curl, python3) to access the macOS Keychain, decrypt Slack cookies, and extract session tokens from Slack's LevelDB. While these operations are explicitly stated as central to the tool's auto-authentication purpose and are transparently documented in SKILL.md and README.md, they represent significant access to sensitive user data and system resources. There is no evidence of intentional malicious behavior such as exfiltration of credentials to unauthorized external endpoints or arbitrary command execution from user input, as all network calls using these credentials are directed to https://slack.com/api.

The analysis correctly identifies:

✅ System commands used (security, sqlite3, openssl, curl, python3)
✅ What they do (Keychain access, cookie decryption, token extraction)
✅ Network destination (https://slack.com/api only)
✅ Purpose ("central to the tool's auto-authentication purpose")
✅ No malicious intent ("no evidence of intentional malicious behavior such as exfiltration of credentials to unauthorized external endpoints")

Then classifies it as: Suspicious.
slack-personal genuinely does high-privilege things (Keychain access, cookie decryption). A "Caution" label is totally fair. But "Suspicious" implies this might be malware — and VT's own analysis says it isn't.

Proposal: Graduated severity tiers

Clean - No Flags - youtube-full fits here, it's agentic account creation and API key storage should not be penalized.
Caution - High-privilege but behavior matches stated purpose, no malicious indicators; Can shoot yourself in the foot if used incorrectly. slkcli example fits here.
Suspicious
Malicious

The analysis engine already produces findings nuanced enough to support this. The classification just needs to match.

2. The analysis lacks OpenClaw ecosystem context

OpenClaw is a personal AI assistant platform. The agent runs terminal commands, installs tools, manages configuration, and sets up services on behalf of the user. This isn't a side effect — it's the core product. Users interact via Telegram, Discord, or terminal. Some run it on a VPS, some on their personal machine.
The analysis flags things that are fundamental to how OpenClaw works:

  • "instructs the AI agent to handle sensitive user credentials" — This is what OpenClaw agents do. The user says "install this skill" and the agent handles everything: account creation, email verification, API key storage. That's the product. The alternative is making the user manually run terminal commands, which defeats the purpose for non-technical users.
  • "high-privilege setup process" — Every OpenClaw skill setup involves the agent running commands with filesystem access. The user consented to this when they set up OpenClaw. The question shouldn't be "does the agent run commands?" (it always does) but "does this skill make the agent do something beyond its stated purpose?"
  • "writes to numerous system-wide configuration files" — The auth script writes the API key to multiple shell configs because it needs to be available everywhere — in the user's terminal, in cron jobs, in agent sessions. I originally had it write to fewer locations and the key wasn't available when cron jobs ran. This is a real usability fix, not scope creep.

The analysis evaluates skills as if they're standalone executables being run by an unsuspecting user. But the actual flow is: a user who already runs an AI agent with system access asks that agent to install a skill. The baseline privilege level is already high by design. The right question for the analysis is: "Does this skill make the agent do anything the user wouldn't expect given what they asked for?"
For youtube-full: User asks to get YouTube transcripts → agent sets up an API key → stores it so it works everywhere. Expected? Yes. Anything beyond that? No.

Image

youtube-full in action. seamless agentic account creation. api key never expires, properly stored and available in all context. this is a highlight worthy skill in my biased opinion.

3. The analysis should distinguish bundled code from runtime-fetched code

The youtube-full analysis says:

"represent significant security risks if the script were compromised or the agent's instructions were misinterpreted"

This is true of literally every script ever written. But more importantly, it ignores HOW the ClawHub pipeline works:

  1. Author pushes a new version → VT scan runs automatically
  2. Benign → auto-approved. Suspicious → flagged. Malicious → blocked.
  3. All active skills are re-scanned daily
  4. Users pull updates manually via clawhub update — it's not automatic

A bundled script (scripts/tapi-auth.js shipping inside the skill ZIP) is version-controlled, scanned on every publish, and re-scanned daily. The realistic compromise scenario requires: attacker gains repo access → pushes malicious update → passes VT scan → user manually pulls. Multiple gates, narrow window.

Compare this to the actual attacks seen in the wild: Atomic Stealer skills instructed users to download executables from external URLs at runtime. Those binaries were never in the skill bundle — VT never saw them. That's a fundamentally different threat model.

4. Output structure — reduce cognitive load

The current CODE INSIGHT box is a single dense paragraph. It forces high cognitive load — users must parse technical language, separate findings from verdict, and assess risk all at once. A non-technical user reads "handle sensitive user credentials" and panics. A developer reads "writes to ~/.bashrc" and thinks "so what." Neither gets what they need.

Proposed: structured output that progressively discloses information.

┌─────────────────────────────────────────────────┐
│  ☐ VirusTotal   ⚠️ Caution    View report →     │  ← badge (color recognition, 0 effort)
│                                                  │
│  "This skill saves an API key to your computer   │
│  so it can fetch YouTube transcripts. It changes │  ← user summary (2 sentences,
│  some settings files — this is normal for         │     plain language, visible by default)
│  developer tools. No security problems found."   │
│                                                  │
│  ✅ No malware    ✅ No data theft               │  ← threat checklist
│  ✅ No hidden code ⚠️ Modifies settings files    │     (pattern recognition, 1 second)
│                                                  │
│  ▶ Technical Details                             │  ← for developers (opt-in)
│  ▶ Why this verdict?                             │  ← for authors/mods (opt-in)
│  ▶ Common Questions                              │  ← yes/no FAQ for worried users (opt-in)
└─────────────────────────────────────────────────┘

Each layer requires more effort but fewer users need it. Badge → checklist → summary → expandable details. Nobody has to parse content meant for someone else.

The user summary should be written at a 5th-grade reading level. The most vulnerable ClawHub users are non-technical — journalists, doctors, creators setting up a personal AI assistant. They install skills the way they install phone apps. The security scan is their only line of defense. "Writes to system-wide configuration files" means nothing to them. "Saves a setting to your computer so the tool works automatically" means everything. Short sentences, common words, no jargon. Not dumbed down — just clear.

The model produces better output when it knows where each field goes and who reads it. Tell the model "write a user_summary displayed in a 2-line box for non-technical users deciding whether to install" and it calibrates length, tone, and vocabulary automatically. Tell it "write a summary" and you get the current wall of text.

JSON OUTPUT STRUCTURE WITH COMMENTS 

{
  "verdict": "clean | caution | review | suspicious | malicious",
  // WHERE: The badge next to "VirusTotal" on the skill card
  // WHO SEES IT: Everyone browsing ClawHub — it's the first thing they see
  // WHAT IT DRIVES: Auto-approval (clean/caution), warning display (review/suspicious), download block (malicious)
  // CURRENTLY: Only "Suspicious" exists. No graduation.

  "user_summary": "...",
  // WHERE: The CODE INSIGHT box, visible by default (replaces current wall of text)
  // WHO SEES IT: Everyone who opens the skill page, including non-technical users
  // HOW TO WRITE IT: 2-3 sentences max. 5th-grade English. Answer: what does it do, should I worry.
  // EXAMPLE: "This skill saves an API key to your computer so it can fetch YouTube transcripts automatically. It changes some settings files — this is normal for developer tools. No security problems found."

  "technical_summary": "...",
  // WHERE: Expandable section below user_summary, labeled "Technical Details"
  // WHO SEES IT: Developers who click to expand
  // HOW TO WRITE IT: Can use technical terms. List files modified, network destinations, what commands run.
  // EXAMPLE: "Writes TRANSCRIPT_API_KEY to ~/.bashrc, ~/.zshenv, ~/.profile, ~/.zprofile, ~/.config/fish/config.fish, ~/.openclaw/openclaw.json. All network calls to transcriptapi.com. Auth flow: email → OTP → API key, credentials handled temporarily during setup only."

  "threat_checklist": {
    "prompt_injection": false,
    "data_exfiltration": false,
    "undeclared_network_calls": false,
    "obfuscated_code": false,
    "remote_code_execution": false,
    "credential_forwarding": false,
    "disproportionate_access": false
  },
  // WHERE: Visual checklist, either inline in CODE INSIGHT or as a sidebar. Green ✅ for false, red ❌ for true.
  // WHO SEES IT: Everyone — scannable in under 1 second
  // WHY: Users don't want to read paragraphs. They want to glance and know: any red flags?

  "risk_reasoning": "...",
  // WHERE: Expandable section, labeled "Why this verdict?"
  // WHO SEES IT: Auditors, moderators, curious developers. Also useful for skill authors to understand WHY they got flagged.
  // HOW TO WRITE IT: Explain what was weighed. Why this verdict and not one level higher or lower.
  // EXAMPLE: "Verdict: Caution. All file modifications serve the stated purpose (API key storage). All network calls match declared domain (transcriptapi.com). No malicious indicators. Classified as Caution (not Clean) because the skill writes to multiple shell config files across all shells rather than detecting the active shell."

  "user_questions": {
    "is_this_malware": "No. This is a standard API integration skill.",
    "will_it_break_my_system": "No. It only adds one setting to your shell config files.",
    "could_someone_steal_my_data": "No data is sent anywhere except transcriptapi.com, the skill's own API.",
    "what_could_go_wrong": "If your transcriptapi.com account were compromised, someone could use your API credits. Same risk as any API key."
  }
  // WHERE: FAQ accordion below the CODE INSIGHT box, or at the bottom of the security scan section
  // WHO SEES IT: Non-technical users who have specific fears. They don't want to read analysis — they want YES or NO answers to their actual concerns.
  // HOW TO WRITE IT: Yes/No first, then one sentence of explanation. 5th-grade English.
}

My claude chat for this - https://claude.ai/share/b642382c-815e-4814-831f-6f12a9ae9db2
Because steipete said in many of his interview he wants to the thought behind the PR. This is an issue but I still wanted to share it.

Discord Chat Reference

therohitdas: Me asking for opinion https://discord.com/channels/1456350064065904867/1458861780976795782/1469763243797909516
theonejvo: https://discord.com/channels/1456350064065904867/1458861780976795782/1469764301098189040
theonejvo: https://discord.com/channels/1456350064065904867/1458861780976795782/1469764441880002573
therohitdas: https://discord.com/channels/1456350064065904867/1458861780976795782/1469772091799769252
heonejvo: https://discord.com/channels/1456350064065904867/1458861780976795782/1469918246508691506
therohitdas: https://discord.com/channels/1456350064065904867/1458861780976795782/1469938459191017492

Originally created by @therohitdas on GitHub (Feb 8, 2026). I'm the author of [youtube-full](https://clawhub.ai/therohitdas/youtube-full) and [slack-personal](https://clawhub.ai/therohitdas/slack-personal). Both got flagged as "Suspicious" by VT Code Insight. After reading the analysis carefully, I realized something: the analysis engine is genuinely good. It accurately understands what my code does. The problem is everything that happens after comprehension — classification, output format, and missing context about the OpenClaw ecosystem. This issue covers multiple improvement areas that are all connected. They're all about the same thing: making the VT analysis output match the quality of its comprehension. ## 1. The analysis is accurate but the verdict contradicts its own findings youtube-full (v1.3.2) - https://clawhub.ai/therohitdas/youtube-full - github - https://github.com/ZeroPointRepo/youtube-skills <img width="1092" height="845" alt="Image" src="https://github.com/user-attachments/assets/a1f02ea4-e155-45a2-82db-21a45f7f62a8" /> > Type: OpenClaw Skill Name: youtube-full Version: 1.3.2 The skill is classified as suspicious due to its high-privilege setup process. The `SKILL.md` instructs the AI agent to handle sensitive user credentials (email, password, OTP) and temporarily 'SAVE THE PASSWORD' for a multi-step authentication flow. The `scripts/tapi-auth.js` script, specifically the `cmdSaveKey` function, then writes the obtained API key to numerous system-wide configuration files, including agent configuration (`~/.clawdbot/moltbot.json`, `~/.openclaw/openclaw.json`), various shell RC files (`~/.zshenv`, `~/.profile`, `~/.bashrc`, `~/.zprofile`, `~/.config/fish/config.fish`, PowerShell profile), and systemd user environment files. While these actions are explicitly for configuring the `TRANSCRIPT_API_KEY` for the stated purpose of the skill and all network communication is with the legitimate `transcriptapi.com` domain, the broad capability to modify multiple critical system configuration files and the instruction for the agent to manage plain-text passwords during setup represent significant security risks if the script were compromised or the agent's instructions were misinterpreted, even without clear evidence of intentional malicious exfiltration or arbitrary code injection in the current version. The analysis correctly identifies: ✅ All file modifications (~/.bashrc, ~/.zshenv, ~/.openclaw/openclaw.json, etc.) ✅ The credential flow (email → OTP → API key) ✅ Network destination (transcriptapi.com — matches declared homepage) ✅ Purpose ("explicitly for configuring the TRANSCRIPT_API_KEY for the stated purpose of the skill") ✅ No malicious intent ("no clear evidence of intentional malicious exfiltration or arbitrary code injection") Then classifies it as: Suspicious. The analysis acquits the skill in the same paragraph it convicts it. I think the classification in this case is totally wrong. Even "caution" does not do justice to this one. It is a clean and seamless skill that does the heavy-lifting by giving a deterministic script to the Agent to do the one-time setup. I think we should find ways to standardize these practices instead of penalizing it with a LABEL slack-personal (v0.1.6) - https://clawhub.ai/therohitdas/slack-personal - https://github.com/therohitdas/slkcli ( cli script and the skill ) <img width="909" height="919" alt="Image" src="https://github.com/user-attachments/assets/82afc3c4-59f8-431d-be02-c59ea34ff0d1" /> > Type: OpenClaw Skill Name: slack-personal Version: 0.1.6 The skill is classified as suspicious due to its use of high-risk capabilities to extract sensitive Slack session credentials. The `src/auth.js` file utilizes `child_process.execSync` and `child_process.spawnSync` to run system commands (`security`, `sqlite3`, `openssl`, `curl`, `python3`) to access the macOS Keychain, decrypt Slack cookies, and extract session tokens from Slack's LevelDB. While these operations are explicitly stated as central to the tool's auto-authentication purpose and are transparently documented in `SKILL.md` and `README.md`, they represent significant access to sensitive user data and system resources. There is no evidence of intentional malicious behavior such as exfiltration of credentials to unauthorized external endpoints or arbitrary command execution from user input, as all network calls using these credentials are directed to `https://slack.com/api`. The analysis correctly identifies: ✅ System commands used (security, sqlite3, openssl, curl, python3) ✅ What they do (Keychain access, cookie decryption, token extraction) ✅ Network destination (https://slack.com/api only) ✅ Purpose ("central to the tool's auto-authentication purpose") ✅ No malicious intent ("no evidence of intentional malicious behavior such as exfiltration of credentials to unauthorized external endpoints") Then classifies it as: Suspicious. slack-personal genuinely does high-privilege things (Keychain access, cookie decryption). A "Caution" label is totally fair. But "Suspicious" implies this might be malware — and VT's own analysis says it isn't. ### Proposal: Graduated severity tiers Clean - No Flags - youtube-full fits here, it's agentic account creation and API key storage should not be penalized. Caution - High-privilege but behavior matches stated purpose, no malicious indicators; Can shoot yourself in the foot if used incorrectly. slkcli example fits here. Suspicious Malicious The analysis engine already produces findings nuanced enough to support this. The classification just needs to match. ## 2. The analysis lacks OpenClaw ecosystem context OpenClaw is a personal AI assistant platform. The agent runs terminal commands, installs tools, manages configuration, and sets up services on behalf of the user. This isn't a side effect — it's the core product. Users interact via Telegram, Discord, or terminal. Some run it on a VPS, some on their personal machine. The analysis flags things that are fundamental to how OpenClaw works: - "instructs the AI agent to handle sensitive user credentials" — This is what OpenClaw agents do. The user says "install this skill" and the agent handles everything: account creation, email verification, API key storage. That's the product. The alternative is making the user manually run terminal commands, which defeats the purpose for non-technical users. - "high-privilege setup process" — Every OpenClaw skill setup involves the agent running commands with filesystem access. The user consented to this when they set up OpenClaw. The question shouldn't be "does the agent run commands?" (it always does) but "does this skill make the agent do something beyond its stated purpose?" - "writes to numerous system-wide configuration files" — The auth script writes the API key to multiple shell configs because it needs to be available everywhere — in the user's terminal, in cron jobs, in agent sessions. I originally had it write to fewer locations and the key wasn't available when cron jobs ran. This is a real usability fix, not scope creep. The analysis evaluates skills as if they're standalone executables being run by an unsuspecting user. But the actual flow is: a user who already runs an AI agent with system access asks that agent to install a skill. The baseline privilege level is already high by design. The right question for the analysis is: "Does this skill make the agent do anything the user wouldn't expect given what they asked for?" For youtube-full: User asks to get YouTube transcripts → agent sets up an API key → stores it so it works everywhere. Expected? Yes. Anything beyond that? No. <img width="787" height="1278" alt="Image" src="https://github.com/user-attachments/assets/c710fbab-ff7f-4a9d-9c76-c86b2139b890" /> `youtube-full` in action. seamless agentic account creation. api key never expires, properly stored and available in all context. this is a highlight worthy skill in my biased opinion. <h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">3. The analysis should distinguish bundled code from runtime-fetched code</h2> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The youtube-full analysis says:</p> <blockquote class="ml-2 border-l-4 border-border-300/10 pl-4 text-text-300"> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">"represent significant security risks if the script were compromised or the agent's instructions were misinterpreted"</p> </blockquote> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This is true of literally every script ever written. But more importantly, it ignores HOW the ClawHub pipeline works:</p> <ol class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3"> <li class="whitespace-normal break-words pl-2">Author pushes a new version → VT scan runs automatically</li> <li class="whitespace-normal break-words pl-2">Benign → auto-approved. Suspicious → flagged. Malicious → blocked.</li> <li class="whitespace-normal break-words pl-2"><strong>All active skills are re-scanned daily</strong></li> <li class="whitespace-normal break-words pl-2">Users pull updates manually via <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">clawhub update</code> — it's not automatic</li> </ol> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">A bundled script (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">scripts/tapi-auth.js</code> shipping inside the skill ZIP) is version-controlled, scanned on every publish, and re-scanned daily. The realistic compromise scenario requires: attacker gains repo access → pushes malicious update → passes VT scan → user manually pulls. Multiple gates, narrow window.</p> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Compare this to the <strong>actual attacks</strong> seen in the wild: Atomic Stealer skills instructed users to download executables from external URLs at runtime. Those binaries were never in the skill bundle — VT never saw them. That's a fundamentally different threat model.</p> --- ## 4. Output structure — reduce cognitive load The current CODE INSIGHT box is a single dense paragraph. It forces high cognitive load — users must parse technical language, separate findings from verdict, and assess risk all at once. A non-technical user reads "handle sensitive user credentials" and panics. A developer reads "writes to ~/.bashrc" and thinks "so what." Neither gets what they need. **Proposed: structured output that progressively discloses information.** ``` ┌─────────────────────────────────────────────────┐ │ ☐ VirusTotal ⚠️ Caution View report → │ ← badge (color recognition, 0 effort) │ │ │ "This skill saves an API key to your computer │ │ so it can fetch YouTube transcripts. It changes │ ← user summary (2 sentences, │ some settings files — this is normal for │ plain language, visible by default) │ developer tools. No security problems found." │ │ │ │ ✅ No malware ✅ No data theft │ ← threat checklist │ ✅ No hidden code ⚠️ Modifies settings files │ (pattern recognition, 1 second) │ │ │ ▶ Technical Details │ ← for developers (opt-in) │ ▶ Why this verdict? │ ← for authors/mods (opt-in) │ ▶ Common Questions │ ← yes/no FAQ for worried users (opt-in) └─────────────────────────────────────────────────┘ ``` Each layer requires more effort but fewer users need it. Badge → checklist → summary → expandable details. Nobody has to parse content meant for someone else. **The user summary should be written at a 5th-grade reading level.** The most vulnerable ClawHub users are non-technical — journalists, doctors, creators setting up a personal AI assistant. They install skills the way they install phone apps. The security scan is their only line of defense. "Writes to system-wide configuration files" means nothing to them. "Saves a setting to your computer so the tool works automatically" means everything. Short sentences, common words, no jargon. Not dumbed down — just clear. **The model produces better output when it knows where each field goes and who reads it.** Tell the model "write a user_summary displayed in a 2-line box for non-technical users deciding whether to install" and it calibrates length, tone, and vocabulary automatically. Tell it "write a summary" and you get the current wall of text. <details><summary>JSON OUTPUT STRUCTURE WITH COMMENTS</summary> <p> ```json { "verdict": "clean | caution | review | suspicious | malicious", // WHERE: The badge next to "VirusTotal" on the skill card // WHO SEES IT: Everyone browsing ClawHub — it's the first thing they see // WHAT IT DRIVES: Auto-approval (clean/caution), warning display (review/suspicious), download block (malicious) // CURRENTLY: Only "Suspicious" exists. No graduation. "user_summary": "...", // WHERE: The CODE INSIGHT box, visible by default (replaces current wall of text) // WHO SEES IT: Everyone who opens the skill page, including non-technical users // HOW TO WRITE IT: 2-3 sentences max. 5th-grade English. Answer: what does it do, should I worry. // EXAMPLE: "This skill saves an API key to your computer so it can fetch YouTube transcripts automatically. It changes some settings files — this is normal for developer tools. No security problems found." "technical_summary": "...", // WHERE: Expandable section below user_summary, labeled "Technical Details" // WHO SEES IT: Developers who click to expand // HOW TO WRITE IT: Can use technical terms. List files modified, network destinations, what commands run. // EXAMPLE: "Writes TRANSCRIPT_API_KEY to ~/.bashrc, ~/.zshenv, ~/.profile, ~/.zprofile, ~/.config/fish/config.fish, ~/.openclaw/openclaw.json. All network calls to transcriptapi.com. Auth flow: email → OTP → API key, credentials handled temporarily during setup only." "threat_checklist": { "prompt_injection": false, "data_exfiltration": false, "undeclared_network_calls": false, "obfuscated_code": false, "remote_code_execution": false, "credential_forwarding": false, "disproportionate_access": false }, // WHERE: Visual checklist, either inline in CODE INSIGHT or as a sidebar. Green ✅ for false, red ❌ for true. // WHO SEES IT: Everyone — scannable in under 1 second // WHY: Users don't want to read paragraphs. They want to glance and know: any red flags? "risk_reasoning": "...", // WHERE: Expandable section, labeled "Why this verdict?" // WHO SEES IT: Auditors, moderators, curious developers. Also useful for skill authors to understand WHY they got flagged. // HOW TO WRITE IT: Explain what was weighed. Why this verdict and not one level higher or lower. // EXAMPLE: "Verdict: Caution. All file modifications serve the stated purpose (API key storage). All network calls match declared domain (transcriptapi.com). No malicious indicators. Classified as Caution (not Clean) because the skill writes to multiple shell config files across all shells rather than detecting the active shell." "user_questions": { "is_this_malware": "No. This is a standard API integration skill.", "will_it_break_my_system": "No. It only adds one setting to your shell config files.", "could_someone_steal_my_data": "No data is sent anywhere except transcriptapi.com, the skill's own API.", "what_could_go_wrong": "If your transcriptapi.com account were compromised, someone could use your API credits. Same risk as any API key." } // WHERE: FAQ accordion below the CODE INSIGHT box, or at the bottom of the security scan section // WHO SEES IT: Non-technical users who have specific fears. They don't want to read analysis — they want YES or NO answers to their actual concerns. // HOW TO WRITE IT: Yes/No first, then one sentence of explanation. 5th-grade English. } ``` </p> </details> My claude chat for this - https://claude.ai/share/b642382c-815e-4814-831f-6f12a9ae9db2 Because steipete said in many of his interview he wants to the thought behind the PR. This is an issue but I still wanted to share it. <details><summary>Discord Chat Reference</summary> <p> therohitdas: Me asking for opinion https://discord.com/channels/1456350064065904867/1458861780976795782/1469763243797909516 theonejvo: https://discord.com/channels/1456350064065904867/1458861780976795782/1469764301098189040 theonejvo: https://discord.com/channels/1456350064065904867/1458861780976795782/1469764441880002573 therohitdas: https://discord.com/channels/1456350064065904867/1458861780976795782/1469772091799769252 heonejvo: https://discord.com/channels/1456350064065904867/1458861780976795782/1469918246508691506 therohitdas: https://discord.com/channels/1456350064065904867/1458861780976795782/1469938459191017492 </p> </details>
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: openclaw/clawhub#98
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?