Found by the security review #73. Severity: low, pending the owner's answer on whether the key is live.
What is wrong
The commented S3 block in config.example.yml holds a 20-character access key id and a 40-character secret (:277-278) for the endpoint at :266, a private address. storage_url (:260) names an internal rclone remote and pool path. This is a different file and key pair from #137, and unlike that one it is still in the current tree. REPO_POLICIES.md:238 says never commit secrets. Nothing in the repo can show whether the key is valid.
Acceptable
Those lines use the same placeholders as the config init template (internal/cli/config.go:192-193: YOUR_ACCESS_KEY, YOUR_SECRET_KEY), a neutral endpoint with https://, a neutral bucket name and a neutral storage_url. No history rewrite.
Do this before #74 item 9 links the file from the README.
Definition of done
config.example.yml contains no key-shaped value, private address or internal host name, and still loads in whatever test reads it.
make check green.
Revoking the key is the owner's action and is asked on #73.
Line numbers are as of next at 6fcd8e1.
model: fable-5-1
Found by the security review https://git.eeqj.de/sneak/vaultik/issues/73. Severity: **low**, pending the owner's answer on whether the key is live.
## What is wrong
The commented S3 block in `config.example.yml` holds a 20-character access key id and a 40-character secret (`:277-278`) for the endpoint at `:266`, a private address. `storage_url` (`:260`) names an internal rclone remote and pool path. This is a different file and key pair from https://git.eeqj.de/sneak/vaultik/issues/137, and unlike that one it is still in the current tree. `REPO_POLICIES.md:238` says never commit secrets. Nothing in the repo can show whether the key is valid.
## Acceptable
Those lines use the same placeholders as the `config init` template (`internal/cli/config.go:192-193`: `YOUR_ACCESS_KEY`, `YOUR_SECRET_KEY`), a neutral endpoint with `https://`, a neutral bucket name and a neutral `storage_url`. No history rewrite.
Do this before https://git.eeqj.de/sneak/vaultik/issues/74 item 9 links the file from the README.
## Definition of done
1. `config.example.yml` contains no key-shaped value, private address or internal host name, and still loads in whatever test reads it.
2. `make check` green.
Revoking the key is the owner's action and is asked on https://git.eeqj.de/sneak/vaultik/issues/73.
Line numbers are as of `next` at `6fcd8e1`.
model: fable-5-1
Owner decision needed. A PR is scrubbing config.example.yml to neutral placeholders (the file-hygiene part of this issue). That does not, by itself, address the question this issue flags as pending: was this S3 access key / secret ever a live credential? If it was, scrubbing the current file does not remove it from git history, and it should be rotated -- an action only you can take. If it was always a dummy, nothing further is needed. Please confirm which; the scrub lands regardless.
Model: opus-4-8
Owner decision needed. A PR is scrubbing `config.example.yml` to neutral placeholders (the file-hygiene part of this issue). That does not, by itself, address the question this issue flags as pending: **was this S3 access key / secret ever a live credential?** If it was, scrubbing the current file does not remove it from git history, and it should be rotated -- an action only you can take. If it was always a dummy, nothing further is needed. Please confirm which; the scrub lands regardless.
Model: opus-4-8
sneak
was assigned by clawbot2026-09-22 13:13:05 +02:00
Replaced the leaked S3 access key id, secret, private http:// endpoint, and internal rclone storage_url in config.example.yml with the neutral placeholders the config init template uses (YOUR_ACCESS_KEY / YOUR_SECRET_KEY, https://s3.example.com, mybucket, rclone://myremote/path/to/backups). No behavior or other keys changed.
Added a test: since the credentials sit in the commented-out s3: block the loader never parses, it checks the raw file text for the placeholders and for the absence of any http:// endpoint, and loads the file to confirm the active storage_url still parses. make check green.
Key revocation remains the owner's action per #73.
Model: opus-4-8
Done in https://git.eeqj.de/sneak/vaultik/pulls/190.
Replaced the leaked S3 access key id, secret, private `http://` endpoint, and internal rclone `storage_url` in `config.example.yml` with the neutral placeholders the `config init` template uses (`YOUR_ACCESS_KEY` / `YOUR_SECRET_KEY`, `https://s3.example.com`, `mybucket`, `rclone://myremote/path/to/backups`). No behavior or other keys changed.
Added a test: since the credentials sit in the commented-out `s3:` block the loader never parses, it checks the raw file text for the placeholders and for the absence of any `http://` endpoint, and loads the file to confirm the active `storage_url` still parses. `make check` green.
Key revocation remains the owner's action per https://git.eeqj.de/sneak/vaultik/issues/73.
Model: opus-4-8
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found by the security review #73. Severity: low, pending the owner's answer on whether the key is live.
What is wrong
The commented S3 block in
config.example.ymlholds a 20-character access key id and a 40-character secret (:277-278) for the endpoint at:266, a private address.storage_url(:260) names an internal rclone remote and pool path. This is a different file and key pair from #137, and unlike that one it is still in the current tree.REPO_POLICIES.md:238says never commit secrets. Nothing in the repo can show whether the key is valid.Acceptable
Those lines use the same placeholders as the
config inittemplate (internal/cli/config.go:192-193:YOUR_ACCESS_KEY,YOUR_SECRET_KEY), a neutral endpoint withhttps://, a neutral bucket name and a neutralstorage_url. No history rewrite.Do this before #74 item 9 links the file from the README.
Definition of done
config.example.ymlcontains no key-shaped value, private address or internal host name, and still loads in whatever test reads it.make checkgreen.Revoking the key is the owner's action and is asked on #73.
Line numbers are as of
nextat6fcd8e1.model: fable-5-1
clawbot referenced this issue2026-09-22 09:10:30 +02:00
Owner decision needed. A PR is scrubbing
config.example.ymlto neutral placeholders (the file-hygiene part of this issue). That does not, by itself, address the question this issue flags as pending: was this S3 access key / secret ever a live credential? If it was, scrubbing the current file does not remove it from git history, and it should be rotated -- an action only you can take. If it was always a dummy, nothing further is needed. Please confirm which; the scrub lands regardless.Model: opus-4-8
Done in #190.
Replaced the leaked S3 access key id, secret, private
http://endpoint, and internal rclonestorage_urlinconfig.example.ymlwith the neutral placeholders theconfig inittemplate uses (YOUR_ACCESS_KEY/YOUR_SECRET_KEY,https://s3.example.com,mybucket,rclone://myremote/path/to/backups). No behavior or other keys changed.Added a test: since the credentials sit in the commented-out
s3:block the loader never parses, it checks the raw file text for the placeholders and for the absence of anyhttp://endpoint, and loads the file to confirm the activestorage_urlstill parses.make checkgreen.Key revocation remains the owner's action per #73.
Model: opus-4-8