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

Feature Request: Verified Publisher badges to reduce false positive security warnings #104

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

Originally created by @a692570 on GitHub (Feb 10, 2026).

Summary

Implement a verified publisher badge system for ClawhHub to distinguish legitimate integrations from unknown publishers.

Problem

The current security scanner labels standard integration capabilities as "suspicious":

  • Modifying gateway config during setup
  • Running persistent background processes
  • Self-updating from GitHub

These behaviors are required for any real-time integration that works out of the box. The scanner correctly identifies capabilities but cannot distinguish a Telnyx-published skill (modifying config for voice) from an unknown publisher's skill.

Impact

Enterprise adoption is blocked when legitimate companies see their skills flagged alongside unknown publishers. A Fortune 500 telecom company's voice integration should not carry the same warning as anonymous code.

Proposed Solution

Add publisher identity verification with a "Verified Publisher" badge:

  1. Verification methods:

    • GitHub org matching (skill repo → known org)
    • DNS TXT record verification (company domain)
    • Business verification (manual review for established entities)

  2. UI changes:

    • Verified badge on skill cards
    • "Published by [Organization] (verified)" header
    • Risk labels that distinguish "untrusted publisher with X capabilities" from "verified publisher with X capabilities"

  3. Integration with security analysis:

    • Pass publisher verification status to the VT analysis pipeline
    • Adjust risk scoring based on publisher trust tier

Rationale

This approach matches established ecosystem patterns:

  • npm verified publishers
  • Chrome Web Store verified developers
  • PyPI trusted publishers

All of these systems separate capability awareness from publisher trust. ClawhHub should do the same.

Related

  • #184 (paid certificate for code review) - complementary, not overlapping
  • #181 (VT pipeline improvements) - complementary, this adds publisher identity to the analysis
Originally created by @a692570 on GitHub (Feb 10, 2026). ## Summary Implement a verified publisher badge system for ClawhHub to distinguish legitimate integrations from unknown publishers. ## Problem The current security scanner labels standard integration capabilities as "suspicious": - Modifying gateway config during setup - Running persistent background processes - Self-updating from GitHub These behaviors are required for any real-time integration that works out of the box. The scanner correctly identifies capabilities but cannot distinguish a Telnyx-published skill (modifying config for voice) from an unknown publisher's skill. ## Impact Enterprise adoption is blocked when legitimate companies see their skills flagged alongside unknown publishers. A Fortune 500 telecom company's voice integration should not carry the same warning as anonymous code. ## Proposed Solution Add publisher identity verification with a "Verified Publisher" badge: 1. **Verification methods:** - GitHub org matching (skill repo → known org) - DNS TXT record verification (company domain) - Business verification (manual review for established entities) 2. **UI changes:** - Verified badge on skill cards - "Published by [Organization] (verified)" header - Risk labels that distinguish "untrusted publisher with X capabilities" from "verified publisher with X capabilities" 3. **Integration with security analysis:** - Pass publisher verification status to the VT analysis pipeline - Adjust risk scoring based on publisher trust tier ## Rationale This approach matches established ecosystem patterns: - npm verified publishers - Chrome Web Store verified developers - PyPI trusted publishers All of these systems separate capability awareness from publisher trust. ClawhHub should do the same. ## Related - #184 (paid certificate for code review) - complementary, not overlapping - #181 (VT pipeline improvements) - complementary, this adds publisher identity to the analysis
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#104
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?