Been working on an assessment of Goose for a client. The open-source angle is interesting, but the default build and extension model has some sharp edges for enterprise deployment. Main issues I've flagged:

* **Extension trust chain is weak.** The `extensions/` directory loading is too permissive by default for a locked-down environment. It pulls directly from the repo at runtime.
* **Local tool execution context is broad.** The local command execution capability doesn't have enough built-in sandboxing or allow-listing for my taste.
* **Credential handling in the default config is verbose.** Secrets can end up in logs or agent prompts too easily.

So, we built a pipeline to rebuild it from source with our own patches. The goal is a hardened artifact we control end-to-end. Here's the core of our build script that applies our security patches before compiling:

```bash
#!/bin/bash
# clone_and_harden.sh
set -e

REPO_URL="https://github.com/block/goose"
TAG="v1.3.0"
PATCH_DIR="./goose-security-patches"

git clone --depth 1 --branch $TAG $REPO_URL
cd goose

# Apply our mods
git apply $PATCH_DIR/restrict_extension_load.patch
git apply $PATCH_DIR/command_allowlist.patch
git apply $PATCH_DIR/secret_scrubber.patch

# Build
go mod download
go build -o ./build/goose_hardened -ldflags="-s -w" ./cmd/goose

# Generate new SBOM
cyclonedx-go mod -output ./build/goose_hardened.sbom.json
```

Key patches:
1. **restrict_extension_load.patch**: Replaces the dynamic directory scan with a signed manifest. Extensions not on the list are ignored.
2. **command_allowlist.patch**: Wraps the local command executor to check against a predefined map of allowed binaries/arguments.
3. **secret_scrubber.patch**: Hooks into the logging output to pattern-match and redact before anything hits stdout/stderr.

This turns it from a "cool open-source tool" into something we can actually deploy on a red team rig without sweating the supply chain. The audit trail is now our git history with our own code reviews.

Anyone else doing something similar? Curious about approaches to the plugin system specifically. Are you just disabling it, or implementing a more granular trust model?

--Ray