DEBUG=true prints the session encryption key and the admin password hash to the log #207

New Issue

2026-08-20T05:48:04+02:00

clawbot commented

2026-08-20 05:48:04 +02:00

With DEBUG=true the GORM SQL log (internal/gormlog/gormlog.go, wired at internal/database/database.go:161) prints fully interpolated statements, which at first boot includes:

INSERT INTO settings ... carrying the base64 session encryption key
INSERT INTO users ... carrying the Argon2id password hash

The session key is the whole of the session security model: anyone holding it can forge an authenticated session cookie. Debug logs are routinely pasted into issues and chats, which is exactly the exposure path that #179 closed for Sentry.

#178 already routed GORM through slog and bounded it. This is the remaining problem: it is not the volume of the statement but the values inside it.

Definition of done:

statements touching settings and users are redacted in the GORM logger — log the statement shape, never the bound values, for those tables
a broader values-off mode is acceptable and probably better: log SQL with placeholders rather than interpolated values, at every level
a test boots with DEBUG=true on a fresh database and asserts neither the session key nor a password hash appears in captured log output
README notes what DEBUG=true does and does not expose

With `DEBUG=true` the GORM SQL log (`internal/gormlog/gormlog.go`, wired at `internal/database/database.go:161`) prints fully interpolated statements, which at first boot includes: - `INSERT INTO settings ...` carrying the base64 session encryption key - `INSERT INTO users ...` carrying the Argon2id password hash The session key is the whole of the session security model: anyone holding it can forge an authenticated session cookie. Debug logs are routinely pasted into issues and chats, which is exactly the exposure path that #179 closed for Sentry. #178 already routed GORM through `slog` and bounded it. This is the remaining problem: it is not the volume of the statement but the values inside it. Definition of done: - statements touching `settings` and `users` are redacted in the GORM logger — log the statement shape, never the bound values, for those tables - a broader values-off mode is acceptable and probably better: log SQL with placeholders rather than interpolated values, at every level - a test boots with `DEBUG=true` on a fresh database and asserts neither the session key nor a password hash appears in captured log output - README notes what `DEBUG=true` does and does not expose

clawbot added this to the 1.0.0 milestone 2026-08-20 05:48:04 +02:00

clawbot referenced this issue

2026-08-20 05:49:42 +02:00

1.0/mvp #33

~~clawbot referenced this issue 2026-08-20 05:56:52 +02:00~~

Milestone 1.0.0: internet-facing readiness #111

clawbot referenced this issue from a commit

2026-08-20 06:23:24 +02:00

Log SQL with placeholders, never bound values (closes #207)

clawbot referenced a pull request that will close this issue

2026-08-20 06:23:50 +02:00

Log SQL with placeholders, never bound values (closes #207) #222