unkinben
a69318b62d
## Why `ensure: present`/`latest` lets the plugin binaries drift from the sha256 pinned in the terraform-vault catalog (`config/plugins/*.yaml`). On the next OpenBao restart, a drifted binary fails the sha check and the plugin won't launch — a latent footgun (hit exactly this with rancher on `ensure: latest`). ## Changes Pin each secrets plugin to the version whose binary matches its registered catalog sha (all verified against the RPMs in rpm-internal): - `openbao-plugin-secrets-litellm`: **0.1.1** (sha 2263ebcb…) - `openbao-plugin-secrets-gpg`: **0.1.0** (sha 0e92d740…) - `openbao-plugin-secrets-rancher`: **0.1.1** (sha 9e597cd9…; was `ensure: latest`) All three are no-op on the binary (installed versions already match) — this just locks them so a future release can't silently upgrade the binary out of lockstep with the catalog. `openbao-plugins` (base bundle) left unpinned — its version couldn't be verified from the tooling side and it tracks the openbao package, not a catalog sha. ## Note To upgrade a plugin in future: bump the RPM version here **and** the catalog sha256 in terraform-vault in the same change, then `vault write sys/plugins/reload/backend plugin=<name>`. --------- Co-authored-by: Ben Vincent <neotheo@gmail.com> Reviewed-on: #492 Co-authored-by: Ben Vincent <ben@unkin.net> Co-committed-by: Ben Vincent <ben@unkin.net>