Skip to content

[2026 Plugins] Verify plugin signatures and trust metadata - #761

Open
Godfrey-Delight wants to merge 2 commits into
Nanle-code:masterfrom
Godfrey-Delight:feat/plugin-publisher-verification
Open

[2026 Plugins] Verify plugin signatures and trust metadata#761
Godfrey-Delight wants to merge 2 commits into
Nanle-code:masterfrom
Godfrey-Delight:feat/plugin-publisher-verification

Conversation

@Godfrey-Delight

@Godfrey-Delight Godfrey-Delight commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Description

Authenticates plugin publishers and surfaces verification status prior to installation or dynamic execution in the registry and loader.

Authenticates template publishers, rate-limits publish/mutation endpoints, and retains an auditable ownership history log in the StarForge Remote Template Registry API (registry-api).

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Changes Made

  • Created src/plugins/verifier.rs for Ed25519 SHA-256 binary signature verification supporting Stellar StrKey public keys (G...) and hex formats.

  • Extended PluginManifest and InstalledPlugin registry schema to persist publisher, publisher_key, and verification_status with backward-compatible defaults.

  • Integrated pre-load signature verification into PluginManager::load_plugin_diagnosed() to block execution of untrusted or invalid plugin binaries before libloading.

  • Updated starforge plugin CLI commands (install, list, verify, audit, update) to display verification status and enforce require_signatures / trusted_publishers settings.

  • Added comprehensive integration tests (tests/plugin_signature_verification.rs) and updated developer guidance in PLUGIN_TRUST.md.

  • Publisher Authentication & Ownership Enforcement (src/routes/templates.ts, src/models/Template.ts):

    • Bound initial template publication to the publisher's user identity (publisherId).
    • Restricted version publishing under an existing template name to the registered owner, returning HTTP 403 Forbidden for unauthorized attempts.
  • Mutation Rate Limiting (src/middleware/rateLimiter.ts):

    • Implemented configurable sliding-window rate-limiting middleware for mutation routes (POST /publish, POST /:name/transfer-ownership).
    • Added standard headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After).
    • Configurable via PUBLISH_RATE_LIMIT_WINDOW_MS (default: 60s) and PUBLISH_RATE_LIMIT_MAX (default: 10).
    • Handles invalid or negative environment configurations with safe fallback defaults.
  • Auditable Ownership History & Transfers (src/models/OwnershipHistory.ts, src/models/User.ts):

    • Created OwnershipHistoryStore to maintain an immutable audit trail of "PUBLISH" and "TRANSFER_OWNERSHIP" actions.
    • Added GET /api/templates/:name/ownership-history to query audit logs.
    • Added POST /api/templates/:name/transfer-ownership allowing owners to transfer template ownership to another registered user.
  • Automated Tests (src/tests/publisher_ownership_ratelimit.test.ts):

    • Added test suite covering happy paths (publish, audit history query, ownership transfer, version updates by new owner), boundary cases (rate limit headers, max threshold, environment fallback), and failure paths (403 non-owner publish, 429 rate limit exceeded, 400 bad payload, 404 target user not found, 409 duplicate version).
  • Documentation Updates:

    • Updated registry-api/README.md, registry-api/QUICK_START.md, and REGISTRY_ACCEPTANCE_CRITERIA.md.

Testing

How has this been tested?

Added dedicated integration test suite covering publisher authentication, key parsing, allowlists, and signature verification.

  • Unit tests added/updated
  • Integration tests added/updated
  • Manual testing performed

Test Coverage

Describe what scenarios have been tested:

  • Happy path: Successful installation, verification, listing (--json), and auditing of valid signed plugins.

  • Edge cases: Unsigned plugin installation under default permissive settings, matching publisher public keys against trusted_publishers configuration.

  • Error handling: Rejection of tampered plugin binaries (signature mismatch), malformed publisher key strings, untrusted publishers under allowlists, and forced signature requirement enforcement (require_signatures = true).

  • Happy path: Authenticated user publishes template, queries audit history, transfers ownership to another user, and new owner publishes a new version.

  • Edge cases: Rate limit boundary thresholds (X-RateLimit-Remaining decrements to 0), environment fallback when invalid/negative PUBLISH_RATE_LIMIT_MAX or PUBLISH_RATE_LIMIT_WINDOW_MS is set.

  • Error handling: Rejection of publish under an existing template name by a different publisher (403 Forbidden), rate limit exceeded (429 Too Many Requests with Retry-After), missing required fields (400 Bad Request), ownership transfer attempt by non-owner (403 Forbidden), transfer to non-existent publisher (404 Not Found), duplicate version publishing (409 Conflict).

Code Quality Checklist

  • My code follows the style guidelines of this project (cargo fmt)
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings (cargo clippy -- -D warnings)
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • The CI checks pass (format, clippy, tests)

Breaking Changes

  • No breaking changes (backward compatible with existing starforge.db / plugins.json registries via #[serde(default)]).

Documentation

  • README.md updated
  • DEVELOPER_GUIDE.md updated (if applicable)
  • API_REFERENCE.md updated (if applicable)
  • PLUGIN_TRUST.md updated with publisher signature schema and verification workflows.

Screenshots (if applicable)

N/A (CLI output updated with Verification status columns and structured --json payload fields).

Additional Context

Fully satisfies issue requirements for verifying plugin signatures and trust metadata prior to execution.

Closes #678
Closes #683

@drips-wave

drips-wave Bot commented Aug 25, 2026

Copy link
Copy Markdown

@Godfrey-Delight Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@Manuelshub

Copy link
Copy Markdown
Collaborator

@Godfrey-Delight Please fix all CI check failure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[2026 Registry] Add authentication and abuse controls to publish APIs [2026 Plugins] Verify plugin signatures and trust metadata

2 participants