[Feature request]: External Template Extensions Proposal

[mattjoyce]

What do you need?

External Template Extensions Proposal

Overview

Propose adding an external extension system to Fabric that allows users to extend functionality through custom executables while maintaining security through configuration-based verification.

Goals

1. Enable custom integrations with external systems (databases, APIs, tools)
2. Maintain security through verified extensions
3. Leverage existing template system
4. Support multi-language extension development
5. Enable complex automation workflows

Benefits

For Project

Architecture Evolution: Enables moving all extensions external, including current hard-coded features (if desirable), supporting better modularity Independent Development: Teams can maintain their own extensions without coordinating with core Fabric development Rapid Integration: Add new capabilities without modifying Fabric core Extensible Framework: Opens path for new extension types (e.g., output plugins for Obsidian integration) Separation of Concerns: Cleaner core codebase focused on essential functionality

For Users

Private Customization: Create personal extensions without requiring dev team oversight or sharing Technology Choice: Write extensions in any programming language, using familiar tools and libraries Direct Control: Implement custom integrations for personal or organization-specific needs

Extensions System Design

Template Syntax

{{ext:alias:operation:param1|param2|param3}}

Examples:
{{ext:prod-mysql:query:SELECT * FROM users|analytics}}
{{ext:jira:tickets:PROJECT-123}}
{{ext:github:commits:main|last-week}}

Extension Definition (YAML)

name: mysql-plugin      
binary: /usr/local/bin/mysql-plugin
type: executable       
args_format: "-q {1} -d {2}"  
description: "MySQL database query plugin"
author: "Jane Doe"
version: "1.0.0"
env:
  - MYSQL_USER
  - MYSQL_PASS

Security Model

1. Extension Registration

   • Extensions must be registered in Fabric's config
   • Both config and binary hashes are verified
   • Only approved extensions can execute

2. Configuration in ~/.config/fabric/extensions.yaml

Extension Registration

enabled: 
  MYSQL_PROD: 
    config_path: /etc/fabric/extensions/mysql-prod.yaml 
    config_hash: sha256:e234f7... 
    binary_hash: sha256:45de9d... 
disabled:
  JIRA_DEV: 
    config_path: /etc/fabric/extensions/jira-dev.yaml 
    config_hash: sha256:8abc23... 
    binary_hash: sha256:9def45...

3. Integrity Verification

   • SHA-256 used for both config and binary verification
   • Hashes checked before each extension execution
   • Performance impact negligible compared to LLM latency
   • Prevents tampering with approved extensions

4. Extension Management

   
   # Register new extensions
   fabric --addextension ~/extensions/mysql-extension.yaml

List registered extensions

fabric --listextensions

Remove extensions

fabric --rmextensions mysql-extension

### Use Cases

1. **Data Integration**

{{ext:database:query|SELECT metrics FROM systems}} {{ext:api:fetch|/endpoint/data}}

2. **Tool Integration**

{{ext:git:diff|main}} {{ext:docker:status}}

3. **Meta-Operations**

Run fabric in fabric.

{{ext:fabric:analyze|{{input}}}} {{ext:fabric:summarize|{{output}}}}

### No LLM mode
- Optional mode where Fabric only processes templates
- No LLM calls made
- Useful for testing extensions and automation
- `fabric --nollm --pattern my-pattern`

## Security Considerations

1. **Trust Boundary**
- Moves from "trust all executables" to "trust registered extension"
- Security controlled through configuration in .config/fabric
- Existing file permissions protect extension registry

2. **Extension Execution**
- Runs with user permissions
- Environment variables controlled through extension config
- No shell interpolation in command execution

3. **Configuration Protection**
- ~/.config/fabric/.env already contains sensitive data
- Standard Unix file permissions apply
- Single source of truth for extension authorization

4. **Limitations**
- Extension run with user permissions
- No sandboxing implemented
- Trust model relies on extension review and registration
- 3rd party binaries, will inevitably be updated, causing hashes to fail, and require re-registration.  (might need a n update hash command)

## Implementation Notes

1. **Extensions Resolution**
- Check if extension alias exists in extensions.yaml
- Verify both config and binary hashes
- Load extension configuration
- Execute with provided parameters

2. **Hash Verification**
- SHA-256 used for integrity checking
- Hashes computed and verified on each execution
- Performance impact minimal (milliseconds)

3. **Error Handling**
- Clear error messages for missing extenions
- Hash verification failures prevent execution
- Extensions execution errors captured and reported - hmm - maybe

## Future Considerations

1. **Extension Distribution**
- Central repository of verified extensions
- Automated updates and verification
- Version management

2. **Enhanced Security**
- Optional sandboxing
- Resource limitations
- More granular permissions

3. **Extension Development**
- Extension templates
- Development guidelines
- Testing framework

## Security Review Questions

1. Is the trust model appropriate for the use case?
2. Are there additional controls needed for extension execution?
3. Should extension binary locations be restricted?
4. Are there risks in the template parameter passing?
5. Should there be additional restrictions on environment variables?

[mattjoyce]

Changes term to be be 'extension'. Template extension. Extends the templating system.

[mattjoyce]

@eugeis I started looking at this

propose plugin/template/extension.go plugin/template/extension_reg.go plugin/template/extension_exec.go plugin/template/hash.go (there is no global utils package)

[eugeis]

@mattjoyce what do you think about to use something from here?