Remove hardcoded fallback database password from db_engine.py #20

New Issue

cal · 2026-02-20T06:49:38Z

cal commented

2026-02-20 06:49:38 +00:00

app/db_engine.py:21 — The PostgreSQL password fallback is sba_dev_password_2024. Hardcoding it as a default makes it easy to accidentally run against a database without realizing the env var is unset. The fallback should be None or raise if missing.

Priority: medium | Labels: security

`app/db_engine.py:21` — The PostgreSQL password fallback is `sba_dev_password_2024`. Hardcoding it as a default makes it easy to accidentally run against a database without realizing the env var is unset. The fallback should be `None` or `raise` if missing. **Priority**: medium | **Labels**: security

cal added the

ai-working

label 2026-03-06 01:31:02 +00:00

cal referenced this issue from a commit

2026-03-06 01:33:34 +00:00

fix: remove hardcoded fallback database password from db_engine.py (#20)

cal referenced a pull request that will close this issue

2026-03-06 01:33:42 +00:00

fix: remove hardcoded fallback database password from db_engine.py (#20) #55

cal removed the

ai-working

label 2026-03-06 01:33:49 +00:00

cal commented

2026-03-06 01:33:52 +00:00

Fixed in PR #55: #55

Changed os.environ.get('POSTGRES_PASSWORD', 'sba_dev_password_2024') → os.environ.get('POSTGRES_PASSWORD') so the password is None if the env var is unset, causing an immediate connection failure rather than silently using the stale dev credential.

Fixed in PR #55: https://git.manticorum.com/cal/major-domo-database/pulls/55 Changed `os.environ.get('POSTGRES_PASSWORD', 'sba_dev_password_2024')` → `os.environ.get('POSTGRES_PASSWORD')` so the password is `None` if the env var is unset, causing an immediate connection failure rather than silently using the stale dev credential.

cal added the

ai-pr-opened

label 2026-03-06 01:33:55 +00:00

Sign in to join this conversation.