fix: do not log the database password on startup

[bakiburakogun]

The problem

dockerfile_scripts/pgsql/setup.sh prints EXTERNAL_DB verbatim on every start:

echo "Using EXTERNAL_DB, CCB_DB_URL is set to: $EXTERNAL_DB"

On a deployment that uses an external vector database, that means the database password lands in the container log:

Using EXTERNAL_DB, CCB_DB_URL is set to: postgresql+psycopg://ccb:s3cret@10.0.0.5:5433/ccb

docker logs shows it to anyone who can reach the daemon, and any log shipper carries it off the host. We noticed it while bringing up a four node deployment against an external Patroni cluster: the password we had just written to a 0600 env file was in docker logs a minute later.

The change

Redact the credentials before printing. The scheme, user, host and database name — the parts that make the line useful for diagnosis — stay visible:

Using EXTERNAL_DB, CCB_DB_URL is set to: postgresql+psycopg://ccb:***@10.0.0.5:5433/ccb

Testing

postgresql+psycopg://ccb:s3cret@172.17.0.1:5433/ccb   -> postgresql+psycopg://ccb:***@172.17.0.1:5433/ccb
postgresql+psycopg://ccb@host:5432/db                 -> unchanged (no password to hide)
postgresql+psycopg://user:p%40ss:word@h:5432/d        -> postgresql+psycopg://user:***@h:5432/d

bash -n on the script is clean.

Related: I sent the same class of fix to nextcloud/whiteboard in #1316, where the websocket server logged its Redis password the same way.

[bakiburakogun]

pre-commit.ci run

[kyteinsky]

hello,
thanks for the PR!

it seems there is some issue with the sed replacement.
see https://github.com/nextcloud/context_chat_backend/actions/runs/33286580772/job/99755336536?pr=343#step:41:16

EXTERNAL_DB="postgresql+psycopg://root:rootpassword@${{ env.NODE_IP }}:4445/nextcloud"
yields
Using EXTERNAL_DB, CCB_DB_URL is set to: ***10.1.0.218:4445/nextcloud

[bakiburakogun]

Thanks for looking at it. I went through that job output, and I think the *** is coming from the runner rather than from the sed.

The same line on master, without this PR, looks the same. For example run 33121423491 from 27 August, on commit 040adab:

Using EXTERNAL_DB, CCB_DB_URL is set to: ***10.1.0.112:4445/nextcloud

At that point the script still printed $EXTERNAL_DB verbatim, so the masking happens before the line reaches the log and hides the effect of the redaction entirely. Run against the value from the workflow, the expression gives:

$ printf '%s' 'postgresql+psycopg://root:rootpassword@10.1.0.218:4445/nextcloud' | sed -E 's#(://[^:/@]*):[^@]*@#\1:***@#'
postgresql+psycopg://root:***@10.1.0.218:4445/nextcloud

Your review did turn up a real problem, though, just a different one. The character class stopped at the first @, so a password containing one left the rest of it in the log:

postgresql+psycopg://root:p@ss:word@host:5432/db
  ->  postgresql+psycopg://root:***@ss:word@host:5432/db

I have pushed a commit that matches up to the last @ of the authority instead, staying inside [^/] so an @ in a later path segment cannot swallow the host:

input	output
...://root:rootpassword@10.1.0.218:4445/nextcloud	...://root:***@10.1.0.218:4445/nextcloud
...://root:p@ss:word@host:5432/db	...://root:***@host:5432/db
...://root:pw@host:5432/db@name	...://root:***@host:5432/db@name
...://root@10.1.0.218:4445/nextcloud	unchanged
...://10.1.0.218:4445/nextcloud	unchanged

The failing check-ai-trailers run here is the empty GH_TOKEN case that #349 addresses, so it should pass on a re-run now that it is merged.

[kyteinsky]

ah missed that, nice!