Split out of #206, which is scoped for 1.0 to stopping the leak into the per-webhook event databases.
targets.config is stored in plaintext in webhooker.db. For a Slack target the webhookUrl IS the bearer credential; an http target's URL can embed userinfo. The UI masks these on screen but the storage is clear, so anyone with the file has the credentials.
Deferred past 1.0 deliberately: encrypting a column that is read on every delivery needs a key-management story (reuse the session key material, or a dedicated key with rotation and a re-wrap migration), and getting that wrong loses every target config. Not a same-day change, and the file is already trusted-operator-only. #210 documents the exposure in the README backup section as the 1.0 mitigation.
Definition of done:
credential-bearing target config is encrypted at rest in webhooker.db
a documented key source, with rotation and a re-wrap migration for existing rows
a decrypt failure is a loud error, never a silent fall back to treating the value as plaintext
tests cover round trip, rotation, and the decrypt-failure path
Split out of https://git.eeqj.de/sneak/webhooker/issues/206, which is scoped for 1.0 to stopping the leak into the per-webhook event databases.
`targets.config` is stored in plaintext in `webhooker.db`. For a Slack target the `webhookUrl` IS the bearer credential; an `http` target's URL can embed userinfo. The UI masks these on screen but the storage is clear, so anyone with the file has the credentials.
Deferred past 1.0 deliberately: encrypting a column that is read on every delivery needs a key-management story (reuse the session key material, or a dedicated key with rotation and a re-wrap migration), and getting that wrong loses every target config. Not a same-day change, and the file is already trusted-operator-only. https://git.eeqj.de/sneak/webhooker/issues/210 documents the exposure in the README backup section as the 1.0 mitigation.
Definition of done:
- credential-bearing target config is encrypted at rest in `webhooker.db`
- a documented key source, with rotation and a re-wrap migration for existing rows
- a decrypt failure is a loud error, never a silent fall back to treating the value as plaintext
- tests cover round trip, rotation, and the decrypt-failure path
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.
Split out of #206, which is scoped for 1.0 to stopping the leak into the per-webhook event databases.
targets.configis stored in plaintext inwebhooker.db. For a Slack target thewebhookUrlIS the bearer credential; anhttptarget's URL can embed userinfo. The UI masks these on screen but the storage is clear, so anyone with the file has the credentials.Deferred past 1.0 deliberately: encrypting a column that is read on every delivery needs a key-management story (reuse the session key material, or a dedicated key with rotation and a re-wrap migration), and getting that wrong loses every target config. Not a same-day change, and the file is already trusted-operator-only. #210 documents the exposure in the README backup section as the 1.0 mitigation.
Definition of done:
webhooker.db