feat: GitHub-based Plugin Marketplace System

[r-pedraza]

Summary

This PR implements a complete GitHub-based plugin marketplace system for Titan CLI, enabling users to discover, install, and manage plugins directly from the official repository.

Key Features

• GitHub Registry: Centralized registry.json with plugin metadata (official & community)
• Project-Level Installation: Plugins install to .titan/plugins/ (project-specific)
• Dynamic Configuration: JSON Schema-based config wizard on first install
• Secure Secrets: OS keyring integration via SecretManager
• Interactive Marketplace: Browse, search, and install with rich UI
• Plugin Management: Install, uninstall, update (individual or all)
• Validation: Comprehensive plugin validation (metadata, entry points, dependencies)

New Components

Core Classes:

• PluginDownloader: Downloads plugins from GitHub registry
• PluginValidator: Validates plugin structure and metadata
• ConfigSchemaRenderer: Renders interactive config wizard from JSON Schema

Commands:

• titan plugins discover - Interactive marketplace browser
• titan plugins install <name> - Install plugin by name
• titan plugins uninstall <name> - Remove plugin
• titan plugins update <name> - Update to latest version
• titan plugins update --all - Update all plugins

Registry Format:

{
  "plugins": {
    "git": {
      "display_name": "Git Operations",
      "description": "Git client wrapper",
      "category": "official",
      "verified": true,
      "latest_version": "1.0.0",
      "source": "plugins/titan-plugin-git",
      "dependencies": []
    }
  }
}

Architecture Changes

1. PluginRegistry Enhancements:

   • Discovers both entry points (installed) and local plugins (.titan/plugins/)
   • Loads plugins from project-specific directory
   • Supports dynamic plugin loading without restart

2. Message Centralization:

   • Added 102 new messages across 3 classes (PluginDownloader, PluginValidator, ConfigSchema)
   • All user-facing strings in messages.py for i18n readiness

3. Configuration Updates:

   • TitanConfig.set_plugin_config() for saving plugin configs
   • Project-level plugin config merging
   • Respects existing plugin config in .titan/config.toml

Plugin Metadata

All plugins now include plugin.json with:

• name, version, description
• category (official/community)
• dependencies (plugin dependencies)
• min_titan_version (compatibility check)
• entry_point (Python import path)
• configSchema (optional JSON Schema for config)

Testing

• ✅ 220/220 tests passing
• ✅ 0 linting warnings
• ✅ Added comprehensive tests for:
  • Plugin downloader (registry fetch, download, install, uninstall)
  • Plugin validator (metadata, entry points, dependencies)
  • Config schema renderer (wizard, validation, secure storage)

Security

• Secrets stored in OS keyring (never in config files)
• Plugin validation before installation
• Entry point class verification (must inherit from TitanPlugin)
• Dependency resolution with circular dependency detection

Documentation

• Updated README.md with marketplace usage
• Added .gitignore entry for .titan/plugins/
• Created registry.json with 3 official plugins

Type of Change

• New feature (non-breaking change which adds functionality)
• Enhancement (improvement to existing functionality)
• Documentation update

Changes Made

Core Plugin System

1. PluginDownloader (plugin_downloader.py):

   • Fetches registry.json from GitHub
   • Downloads full repo ZIP and extracts plugin
   • Installs to .titan/plugins/ (project-level)
   • Handles versioning and updates

2. PluginValidator (plugin_validator.py):

   • Validates plugin.json structure
   • Checks required fields (name, version, entry_point)
   • Verifies entry point class exists
   • Validates dependencies and compatibility

3. ConfigSchemaRenderer (config_schema_renderer.py):

   • Renders interactive wizard from JSON Schema
   • Supports all JSON Schema types (string, number, boolean, array, object)
   • Handles validation (pattern, min/max, required)
   • Secure storage for secret fields (x-secret: true)

Commands

4. Plugin Marketplace Commands (plugins_marketplace.py):

   • install_plugin_from_marketplace() - Full install flow with wizard
   • uninstall_plugin_from_marketplace() - Clean uninstall
   • discover_plugins() - Interactive marketplace browser
   • update_plugin() - Update single or all plugins

5. Enhanced Plugin Commands (plugins.py):

   • Integrated marketplace commands
   • Updated list to show installed + downloaded plugins

Configuration

6. TitanConfig Updates (config.py):

   • set_plugin_config() method for saving plugin configs
   • Project-level config merging logic

7. PluginRegistry Enhancements (plugin_registry.py):

   • discover_local_plugins() for .titan/plugins/
   • Combined discovery (entry points + local)
   • Dynamic plugin loading

Registry & Templates

8. Plugin Registry (registry.json):

   • Official plugins: git, github, jira
   • Metadata format with categories, versions, descriptions

9. Plugin Metadata Files:

   • plugins/titan-plugin-git/plugin.json
   • plugins/titan-plugin-github/plugin.json
   • plugins/titan-plugin-jira/plugin.json

Messages & Testing

10. Message Centralization (messages.py):

    • Added 3 message classes with 102 total messages
    • All plugin core modules now use msg.* references

11. Comprehensive Tests:

    • test_plugin_downloader.py - 7 tests
    • test_plugin_validator.py - 12 tests
    • test_config_schema_renderer.py - 18 tests

How Has This Been Tested?

Unit Tests

• ✅ All 220 tests passing
• ✅ Plugin downloader: registry fetch, download, install, uninstall
• ✅ Plugin validator: metadata validation, entry point checks
• ✅ Config renderer: wizard flow, validation, secure storage

Manual Testing

• ✅ titan plugins discover - Interactive marketplace works
• ✅ titan plugins install git - Installs with config wizard
• ✅ titan plugins list - Shows installed plugins
• ✅ titan plugins update --all - Updates all plugins
• ✅ titan plugins uninstall git - Clean removal
• ✅ Plugin configuration persists in .titan/config.toml
• ✅ Secrets stored in OS keyring

Edge Cases Tested

• ✅ Installing already-installed plugin (prompts for reinstall)
• ✅ Missing dependencies (shows error with install commands)
• ✅ Invalid plugin structure (validation error)
• ✅ Network errors (graceful error handling)
• ✅ Cancelled config wizard (plugin installs but not configured)

Checklist

• My code follows the project's code style guidelines
• I have performed a self-review of my own code
• I have added tests that prove my feature works
• All new and existing tests pass locally
• I have updated the documentation (README.md, AGENTS.md if needed)
• My changes generate no new warnings or errors
• Any dependent changes have been merged and published

Additional Notes

Future Enhancements

• Plugin versioning with semantic versioning
• Plugin dependencies graph visualization
• Marketplace filters (category, verified, popularity)
• Plugin ratings and reviews
• Plugin search functionality
• Auto-update notifications

Breaking Changes

None - all changes are additive and backward-compatible.

Migration Guide

For existing users:

1. Plugins will continue to work from entry points
2. New plugins can be installed from marketplace
3. Existing config in .titan/config.toml is preserved

---

Co-Authored-By: Claude noreply@anthropic.com

[osc-wiz-app-masmovil]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	1
Secrets	-
IaC Misconfigurations	3  2
SAST Findings	2  1
Software Management Findings	-
Total	2  4  3

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[osc-wiz-app-masmovil]

 Sensitive Data Finding

PII

More Details

Attribute	Value
Data Classifier	PII/Name
Data Classifier ID	BUILTIN-125

Sampled Examples

Key	Value
author	T***n
author	T***n
author	T***n
git.author	T***n
github.author	T***n

Rule ID: BUILTIN-125

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 SAST Finding

Insecure URL handling in Python urllib module (CWE-939)

More Details

The Python urllib module allows applications to open URLs and retrieve data from the web. However, if the URL is not a literal value and can be controlled by an attacker, it can lead to security vulnerabilities. The urllib module supports the "file://" scheme, which means an attacker could potentially read arbitrary files on the system if they can control the URL value.

This vulnerability poses a significant risk as it can lead to unauthorized access to sensitive information, data leaks, and potentially even remote code execution, depending on the application's context and privileges. It is crucial to avoid passing user-controlled input directly to the urllib module's functions without proper validation and sanitization.

Attribute	Value
Impact
Likelihood

Remediation

To mitigate this vulnerability, it is recommended to either:

1. Hardcode the URLs being used in the urllib module, ensuring that they are not derived from user input or other untrusted sources.
2. Use a more secure and modern library like the requests module, which does not support the "file://" scheme by default.

Example using the requests module to issue an HTTPS request:

import requests

# Issue a GET request to https://example.com with a timeout of 10 seconds
response = requests.get('https://example.com', timeout=10)

# Work with the response object
# ...

Rule ID: WS-I011-PYTHON-00053

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 SAST Finding

Insecure URL handling in Python urllib module (CWE-939)

More Details

The Python urllib module allows applications to open URLs and retrieve data from the web. However, if the URL is not a literal value and can be controlled by an attacker, it can lead to security vulnerabilities. The urllib module supports the "file://" scheme, which means an attacker could potentially read arbitrary files on the system if they can control the URL value.

This vulnerability poses a significant risk as it can lead to unauthorized access to sensitive information, data leaks, and potentially even remote code execution, depending on the application's context and privileges. It is crucial to avoid passing user-controlled input directly to the urllib module's functions without proper validation and sanitization.

Attribute	Value
Impact
Likelihood

Remediation

To mitigate this vulnerability, it is recommended to either:

1. Hardcode the URLs being used in the urllib module, ensuring that they are not derived from user input or other untrusted sources.
2. Use a more secure and modern library like the requests module, which does not support the "file://" scheme by default.

Example using the requests module to issue an HTTPS request:

import requests

# Issue a GET request to https://example.com with a timeout of 10 seconds
response = requests.get('https://example.com', timeout=10)

# Work with the response object
# ...

Rule ID: WS-I011-PYTHON-00053

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 SAST Finding

Arbitrary Code Execution via Insecure Import (CWE-706)

More Details

The importlib.import_module() function in Python allows dynamically importing modules at runtime. If the module name is derived from untrusted user input, an attacker could potentially execute arbitrary code on the system by causing a malicious module to be loaded.

Attribute	Value
Impact
Likelihood

Remediation

The importlib.import_module() function in Python allows for dynamic code loading, which can be a security risk if the module name is derived from untrusted user input. An attacker could potentially exploit this vulnerability to execute arbitrary code on the system, leading to various security issues such as code injection, data tampering, or unauthorized access.

To fix this issue, avoid using dynamic values in importlib.import_module() or implement a strict whitelist of allowed module names. If dynamic module loading is necessary, validate and sanitize the input to ensure that only trusted and approved modules are loaded.

Code examples:

// VULNERABLE CODE - Directly using user input for module loading
import importlib

user_input = input("Enter module name: ")
module = importlib.import_module(user_input)

// SECURE CODE - Using a whitelist of allowed modules
import importlib

ALLOWED_MODULES = ["module1", "module2", "module3"]

user_input = input("Enter module name: ")
if user_input in ALLOWED_MODULES:
    module = importlib.import_module(user_input)
else:
    print("Module not allowed")

Additional recommendations:

• Follow the principle of least privilege and only grant the minimum required permissions for module loading.
• Implement input validation and sanitization techniques to prevent code injection attacks.
• Consider using a secure coding framework or library that provides built-in protection against code injection vulnerabilities.
• Adhere to the OWASP Top 10 security guidelines, specifically "A1:2021 - Broken Access Control" and "A3:2021 - Injection."
• Regularly update and maintain the whitelist of allowed modules to ensure it remains secure and up-to-date.

Rule ID: WS-I013-PYTHON-00176

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 IaC Finding

Workflow should not use version pinning for third-party actions
on resource jobs.test.steps[2].uses

More Details

This rule checks that GitHub workflow does not use version pinning on third-party actions. This rule fails when the workflow contains steps that use third-party actions referenced by version tags (like @v1, @v2.3, @v4) instead of specific commits. Using version-tagged actions creates a supply chain security risk, as the version tag could be modified by the action's maintainer to point to malicious code after the calling workflow is created. Even when using specific version tags, the tag could be moved to point to malicious code. To prevent this risk, always pin third-party actions to specific commit SHAs to ensure the exact code being executed is locked and immutable.

Expected

Workflow job 'test' step[2] should pin third-party action to a commit SHA rather than a version tag

Found

Workflow job 'test' step[2] uses version-tagged third-party action: 'snok/install-poetry@v1'

Security Frameworks: wf-id-1, wf-id-175

Rule ID: 7d431072-4eef-466b-b469-4b7681d8f9a1

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 IaC Finding

Workflow should not use version pinning for third-party actions
on resource jobs.test.steps[7].uses

More Details

This rule checks that GitHub workflow does not use version pinning on third-party actions. This rule fails when the workflow contains steps that use third-party actions referenced by version tags (like @v1, @v2.3, @v4) instead of specific commits. Using version-tagged actions creates a supply chain security risk, as the version tag could be modified by the action's maintainer to point to malicious code after the calling workflow is created. Even when using specific version tags, the tag could be moved to point to malicious code. To prevent this risk, always pin third-party actions to specific commit SHAs to ensure the exact code being executed is locked and immutable.

Expected

Workflow job 'test' step[7] should pin third-party action to a commit SHA rather than a version tag

Found

Workflow job 'test' step[7] uses version-tagged third-party action: 'codecov/codecov-action@v3'

Security Frameworks: wf-id-1, wf-id-175

Rule ID: 7d431072-4eef-466b-b469-4b7681d8f9a1

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 IaC Finding

Workflow should have permissions limitations
on resource name

More Details

This rule checks that GitHub workflow has an empty permissions block to enforce least privilege. This rule fails when the workflow doesn't have a permissions block or has a non-empty permissions block with `write-all` scope, which can grant excessive permissions to workflow actions. Excessive permissions in GitHub workflows increase the risk surface in case of a compromise, potentially allowing attackers to access sensitive resources or perform unauthorized actions. To prevent this risk, always implement least privilege by explicitly defining an empty permissions block for all workflows.

Expected

GitHub workflow should have empty permissions block

Found

GitHub workflow doesn't have a permissions block defined

Security Frameworks: wf-id-1, wf-id-175

Rule ID: 65570021-8e03-4ccf-bf86-6bcb9fcc7a97

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 IaC Finding

Workflow should have permissions limitations
on resource name

More Details

This rule checks that GitHub workflow has an empty permissions block to enforce least privilege. This rule fails when the workflow doesn't have a permissions block or has a non-empty permissions block with `write-all` scope, which can grant excessive permissions to workflow actions. Excessive permissions in GitHub workflows increase the risk surface in case of a compromise, potentially allowing attackers to access sensitive resources or perform unauthorized actions. To prevent this risk, always implement least privilege by explicitly defining an empty permissions block for all workflows.

Expected

GitHub workflow should have empty permissions block

Found

GitHub workflow doesn't have a permissions block defined

Security Frameworks: wf-id-1, wf-id-175

Rule ID: 65570021-8e03-4ccf-bf86-6bcb9fcc7a97

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[osc-wiz-app-masmovil]

 IaC Finding

Workflow should not use version pinning for third-party actions
on resource jobs.publish.steps[2].uses

More Details

This rule checks that GitHub workflow does not use version pinning on third-party actions. This rule fails when the workflow contains steps that use third-party actions referenced by version tags (like @v1, @v2.3, @v4) instead of specific commits. Using version-tagged actions creates a supply chain security risk, as the version tag could be modified by the action's maintainer to point to malicious code after the calling workflow is created. Even when using specific version tags, the tag could be moved to point to malicious code. To prevent this risk, always pin third-party actions to specific commit SHAs to ensure the exact code being executed is locked and immutable.

Expected

Workflow job 'publish' step[2] should pin third-party action to a commit SHA rather than a version tag

Found

Workflow job 'publish' step[2] uses version-tagged third-party action: 'snok/install-poetry@v1'

Security Frameworks: wf-id-1, wf-id-175

Rule ID: 7d431072-4eef-466b-b469-4b7681d8f9a1

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate