security: remove leaked database credentials and purge them from history

[arnoldcastro5000]

What this PR does

This PR deletes the file database/database.json.zaven. The file holds PostgreSQL database credentials in plain text. The credentials are public in this repository, so we must remove them.

This PR is step 1 of 2. It removes the secret from the current branch. It does not remove the secret from the git history. A maintainer with admin rights must do step 2. The commands are below. You can copy and paste them.

Why

The file exposes the database user names, the host, and the passwords for three environments. A public repository shows this file to everyone. We treat every exposed credential as compromised.

The credentials are already rotated. The old values no longer work. This PR and the history purge remove the dead values from GitHub.

What changed here

• Deleted database/database.json.zaven.

This file is safe to delete. Nothing references it. It is a stray per-developer db-migrate config, committed by accident with real credentials. No code, script, or CI job reads database.json.zaven.

The application and the migrations already read the database connection from environment variables. knexfile.js uses process.env.DATABASE_URL_SEEDER, and the .env*.example files document DATABASE_URL. db-migrate reads database/database.json, which is not committed (only database.json.example is). So no runtime path depends on the deleted file.

Step 2 — history purge (maintainer with admin only)

The old commit stays in the history after a normal delete. The secret sits in one commit (e10c6de). It is also pinned by 58 tags (v1.8.0 to v1.15.0) and by 5 other branches. You must rewrite the history and force-push.

Requirements on your machine: git (2.24 or newer), python3, and curl. You do not need to install git-filter-repo; Block 1 downloads it.

Run the blocks in order, in one terminal session.

Block 1 — rewrite and verify locally (safe; does not push)

set -euo pipefail
REPO=treetracker-messaging-api
URL=https://github.com/Greenstand/$REPO
FILE=database/database.json.zaven
WORK=/tmp/purge-$REPO

rm -rf "$WORK" && mkdir -p "$WORK"
curl -fsSL https://raw.githubusercontent.com/newren/git-filter-repo/main/git-filter-repo -o "$WORK/git-filter-repo"
chmod +x "$WORK/git-filter-repo"

git clone --mirror "$URL" "$WORK/$REPO.git"
cd "$WORK/$REPO.git"

python3 "$WORK/git-filter-repo" --path "$FILE" --invert-paths

if [ -n "$(git log --all --oneline -- "$FILE")" ]; then
  echo "FAIL: $FILE is still in history"; exit 1
fi
echo "OK: $FILE removed from all refs."
echo "Rewritten repo is at $WORK/$REPO.git . Review it, then lift branch protection and run Block 2."

Manual gate A — lift branch protection

Lift the branch protection on main in the GitHub UI (Settings → Branches), or with your admin token. Record the current rules first, so you can restore them. A protected branch rejects the force-push.

Block 2 — push the rewrite

set -euo pipefail
REPO=treetracker-messaging-api
WORK=/tmp/purge-$REPO
cd "$WORK/$REPO.git"

# git-filter-repo removes the origin remote after the rewrite; add it back.
git remote add origin https://github.com/Greenstand/$REPO
git push --force --all
git push --force --tags
echo "Pushed. Now restore branch protection (Manual gate B), then run Block 3."

Manual gate B — restore branch protection

Restore the branch protection on main with the same rules you recorded in gate A.

Block 3 — verify on a fresh clone (done-bar)

set -euo pipefail
REPO=treetracker-messaging-api
FILE=database/database.json.zaven
V=/tmp/verify-$REPO
rm -rf "$V"
# Use a NORMAL clone, not --mirror. A mirror clone also fetches refs/pull/*,
# which are GitHub-managed read-only refs you cannot rewrite. They would give
# a false failure. A normal clone checks the branches and tags you control.
git clone https://github.com/Greenstand/$REPO "$V" >/dev/null 2>&1
cd "$V"
test -z "$(git log --all --oneline -- "$FILE")" && echo "PASS: file gone from branches and tags" || { echo "FAIL"; exit 1; }
echo "Tags present: $(git tag | wc -l)"

Two verification traps to avoid:

• Do not use git clone --mirror to verify. It fetches the refs/pull/* refs, which you cannot change, so it always shows the secret and reports a false failure.
• Do not pickaxe the host string ondigitalocean.com. That string also appears in the .env*.example and database.json.example files, so it gives a false failure. Verify by file path, as shown.

There are no open pull requests to close. Note: about 32 closed pull requests still keep a refs/pull/N/head copy of the secret. You cannot delete these refs; GitHub Support removes them in step 3. After the push, tell contributors to re-clone or run git reset --hard, because the commit IDs have changed.

Step 3 — residual exposure (maintainer with admin only; manual)

GitHub keeps old commits alive in three places you cannot reach with a push: the refs/pull/* refs (about 32 closed pull requests), the cached commit views, and the ~11 forks. The values are dead, but do the best-effort cleanup:

1. Open a GitHub Support request for this repository. Ask Support to remove the refs/pull/*/head copies of the secret, to purge the cached commit views, and to remove the dangling commit from the shared fork-network storage.
2. Send a short notice to the fork owners (11). Ask them to re-sync or delete the fork.
3. Accept the remaining risk. A fork owner who does not act may still serve the dead value from the fork. We record this as an accepted risk.

Scope

• Rotation is done offline. This PR does not cover rotation.
• Recurrence prevention (secret scanning, config templates) is out of scope.