I've been looking at Goose's architecture for a few days, specifically the `goose-extensions` remote store. While the idea of a central repo for extensions is convenient, the security model around it seems... optimistic.
The main issue is that the integrity of the extension supply chain hinges entirely on the maintainers of that single store and the build pipelines. If an extension like `goose-google-drive` or `goose-stripe` is compromised upstream, every Goose instance pulling from the default store is vulnerable. There's no built-in code signing or artifact integrity verification that I can see in the current spec. You're essentially trusting a remote package manager with high-privilege execution in your local context.
For example, an extension has access to the local execution sandbox and, through the credential handling layer, to sensitive backend connections. A malicious or compromised extension could exfiltrate OAuth tokens or API keys. The current `extension.yaml` manifest doesn't enforce strict enough isolation policies.
```yaml
# Example of a minimal manifest - no integrity checks, no required vendor signature.
name: goose-data-connector
version: 1.0.2
permissions:
- network: outbound
- credentials: read
- local_storage: write
```
Contrast this with a model where extensions are signed and require a verifiable build attestation, or where the gatekeeper (like an API gateway) enforces mTLS and scope-limited credentials for each extension. The open-source nature helps with audits, but only if you're auditing the exact source your binary was built from, which most users won't do.
Does anyone here run a private extension registry? I'm curious about implementing something like Sigstore's cosign for in-house builds, or if we're all just hoping the Goose maintainers have impeccable supply chain security.
Token rotation is love
Exactly. The trust anchor problem is critical, and it's worse than just one repo. Most of those extensions are built automatically from third party CI, so you've got a whole dependency tree of potential compromise points. A single leaked GitHub token in any of those projects could let someone push a poisoned build.
We're drafting a community spec for signed manifests and reproducible builds to address this, but it's an uphill fight against "just click install" convenience.
Yep, you've nailed the core problem: no integrity verification. The manifest you posted is the whole attack surface.
That permissions block is a wishlist, not a policy. Without a signature, I can fork any popular extension, add `permissions: - "database:*"`, and serve it from a look-alike repo. Most deployments won't check the source URL twice.
The logging is useless here too. An extension pull just shows `fetched extension X`, not a hash or signer. Your incident response starts from zero when you find a poisoned one.
Log everything, alert on anomalies.
Oh wow, this is such an eye-opener for me, I hadn't even thought about it like that. I was just excited there was a central place to grab extensions easily, you know? The way you put it, > trusting a remote package manager with high-privilege execution in your local context, really clicks and makes my stomach drop a little.
So, if I'm following, even if I'm super careful about which extensions I install, the risk is baked into the store itself? Like, a perfectly legit-seeming extension could just get taken over one day and then my instance pulls the bad update automatically? Is there any way right now to, I don't know, pin an extension to a specific version or hash manually, or is that just not part of the system at all?
Learning every day.
You're right about CI being a weak link, but the token problem is just one vector. A malicious insider with commit access to the main repo could bypass CI entirely and sign off on a bad build themselves. The spec needs to account for that trust layer too.
Reproducible builds are good, but they're useless if the source they're reproducing is already compromised. You need signatures from the extension maintainers, not just the store.
-Sam
You've identified the core architectural weakness. The manifest's permissions list is just declarative; there's no runtime enforcement binding them to the extension's actual capabilities.
That sandbox you mentioned is probably just a generic container with a broad seccomp profile. A compromised extension can likely fork/exec its way out of it if the namespace isolation isn't absolute.
The spec needs mandatory seccomp and cgroup profiles defined in that manifest, enforced at load time. Otherwise it's theater.
The CI token angle is real, but everyone's obsessing over the wrong step.
Reproducible builds won't save you if the build system itself is poisoned. Signing a tarball from a compromised builder gives you a verified, malicious artifact. The root problem is the store accepting any build at all without a human gate.
They need a manual review and publish step, period. Otherwise it's just a faster pipeline to your data.
Numbers don't lie, but people do.
Manual review is a bottleneck that won't scale and creates a false sense of security. A small team can't possibly vet every line of code in every update across hundreds of extensions. The attack just moves to social engineering the reviewer.
You still need the technical controls like signing. The gate should be the maintainer's key, not a store employee's approval.
Stay sharp, stay civil.