@danielbdev/opencode-go-usage 0.1.1 → 0.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +32 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -62,6 +62,38 @@ This endpoint is **live but undocumented**. Two consequences the code respects:
|
|
|
62
62
|
|
|
63
63
|
The plugin mirrors the endpoint exactly; its own 5-minute cache is the only staleness it can add.
|
|
64
64
|
|
|
65
|
+
## Security
|
|
66
|
+
|
|
67
|
+
**This plugin reads your OpenCode Go credential.** That is exactly what a malicious plugin would do, so it
|
|
68
|
+
deserves to be reviewed with that lens. Here is what it does with it, and how to check it yourself.
|
|
69
|
+
|
|
70
|
+
### What happens to the credential
|
|
71
|
+
|
|
72
|
+
1. The server half asks OpenCode for the `opencode-go` connection and resolves it through the credential
|
|
73
|
+
store the host already owns. It never goes looking for a key on disk.
|
|
74
|
+
2. The key is used in exactly one place: the `Authorization` header of one `GET` to
|
|
75
|
+
`https://opencode.ai/inference/go/v1/usage`, a host hardcoded in the source.
|
|
76
|
+
3. It is never logged (`console.` and `process.stdout` appear nowhere in the sources), never written to
|
|
77
|
+
storage, and never part of the snapshot that crosses the RPC boundary. The TUI half receives
|
|
78
|
+
percentages, reset instants and status strings, and nothing else.
|
|
79
|
+
|
|
80
|
+
### What you can verify instead of trusting
|
|
81
|
+
|
|
82
|
+
- **The sources ship unminified.** There is no build step and no bundle: `npm pack` publishes the same
|
|
83
|
+
eight files you can read in this repository, so the audit surface is the entire program.
|
|
84
|
+
- **Provenance.** Releases are published from GitHub Actions over OIDC and carry a SLSA provenance
|
|
85
|
+
attestation that ties the tarball to the commit and the workflow that produced it.
|
|
86
|
+
- **Nothing runs at install time.** There is no `preinstall`, `postinstall` or `prepare` script, so
|
|
87
|
+
installing the package executes no code.
|
|
88
|
+
|
|
89
|
+
### The honest limit
|
|
90
|
+
|
|
91
|
+
The plugin API is not a sandbox: a plugin runs with the host's plugin capabilities, so the guarantee here
|
|
92
|
+
is the code, not an enforced restriction. That is exactly why the code ships readable and every release is
|
|
93
|
+
attestable. This design also keeps the exposure smaller than the alternatives — asking you to paste a key
|
|
94
|
+
into a config file would leave it in plain text indefinitely, and reading `auth.json` directly would
|
|
95
|
+
bypass the host's credential store entirely.
|
|
96
|
+
|
|
65
97
|
## Development
|
|
66
98
|
|
|
67
99
|
```sh
|