# Secrets rotieren

Anleitung zum Austausch der Zugangsdaten, die versehentlich in `.env.production.save`
im Git gelandet sind.

**Grundregel:** Kein Befehl in dieser Anleitung gibt einen Geheimwert auf dem Bildschirm
aus. Die neuen Werte werden direkt in die Datei geschrieben. Du siehst sie nie, ich sehe
sie nie, und sie landen nicht in der Shell-History (dort steht nur der Befehl, nicht sein
Ergebnis).

---

## Vorab: Was passiert mit den Daten?

Kurz: **Es geht nichts verloren.** Im Einzelnen:

| Was du änderst | Folge für die Daten | Folge für die Nutzer |
|---|---|---|
| `NEXTAUTH_SECRET` | keine | Alle werden ausgeloggt, Login danach normal möglich |
| Datenbank-Passwort | keine | keine |
| `SMTP_PASSWORD` | keine | keine |

Wichtig zu verstehen: **Die Passwörter der Nutzer hängen nicht am `NEXTAUTH_SECRET`.**
Sie liegen als bcrypt-Hashes in der Datenbank und bleiben davon völlig unberührt.
`NEXTAUTH_SECRET` signiert nur die Sitzungs-Cookies. Wird es getauscht, sind die
ausgestellten Cookies ungültig — jeder muss sich **einmal neu anmelden**, mit dem
gewohnten Passwort. Danach ist alles wie vorher.

Beim Datenbank-Passwort änderst du nur die *Zugangsdaten*, nicht die Datenbank.
Tabellen und Inhalte bleiben unangetastet.

---

## Schritt 0 — Sicherheitsnetz

Auf dem Container:

```bash
cd /root/My-Weekly-ToDo-List
cp .env .env.backup-$(date +%F)
chmod 600 .env.backup-*
ls -l .env.backup-*
```

Falls etwas schiefgeht, kommst du damit zurück. Die Sicherung liegt außerhalb von Git
(`.env*` ist ignoriert) — bitte trotzdem später aufräumen.

Zusätzlich ein Datenbank-Backup, bevor du am DB-Zugang drehst:

```bash
bash /root/My-Weekly-ToDo-List/scripts/backup-db.sh
```

---

## Schritt 1 — `NEXTAUTH_SECRET` neu erzeugen

Ein Befehl, der den neuen Wert erzeugt und **direkt** in die Datei schreibt:

```bash
cd /root/My-Weekly-ToDo-List
sed -i "s|^NEXTAUTH_SECRET=.*|NEXTAUTH_SECRET=\"$(openssl rand -base64 32)\"|" .env
```

Kontrolle, ohne den Wert zu zeigen — es wird nur die Länge ausgegeben:

```bash
awk -F= '/^NEXTAUTH_SECRET=/{v=substr($0,index($0,"=")+1); gsub(/"/,"",v); print "Länge:", length(v), "Zeichen"}' .env
```

Erwartet: **44 Zeichen** (32 Byte in Base64). Der alte Wert hatte 20 — also deutlich zu kurz.

---

## Schritt 2 — Datenbank-Passwort rotieren

> **Korrektur:** Eine frühere Fassung dieser Anleitung ging von *Supabase Cloud* aus, mit
> einem Dashboard und einem "Reset database password"-Knopf. Das trifft hier **nicht** zu.
> Deine Supabase-Instanz läuft **selbst gehostet per Docker auf einem eigenen LXC**
> (siehe `scripts/supabase-setup.sh`). Es gibt kein Cloud-Dashboard.

### Wo läuft die Datenbank?

Der Host steht in deiner `.env` auf dem App-Container. So bekommst du ihn heraus, ohne
das Passwort zu zeigen:

```bash
cd /root/My-Weekly-ToDo-List
grep '^DATABASE_URL=' .env | sed -E 's|.*@([^:/]+):([0-9]+).*|Host: \1   Port: \2|'
grep '^DIRECT_URL='   .env | sed -E 's|.*@([^:/]+):([0-9]+).*|Host: \1   Port: \2|'
```

Die Ports sind aus der Konfiguration bekannt:

| Port | Wofür |
|---|---|
| **6543** | Verbindungspooler (Supavisor/pgbouncer) — das ist `DATABASE_URL` |
| **5432** | Postgres direkt — das ist `DIRECT_URL`, für Migrationen |
| **8000** | Supabase API-Gateway |
| **8001** | Supabase Studio, das Web-Dashboard |

Das Studio erreichst du also unter `http://<Host aus dem Befehl oben>:8001`.
**Aber:** Studio hat keinen Knopf zum Ändern des Postgres-Passworts — das geht nur
auf dem Supabase-LXC selbst.

### Lohnt sich das überhaupt?

**Ehrliche Einschätzung: Dieser Schritt hat die niedrigste Priorität von allen dreien.**

- Die Datenbank hört auf einer **privaten LAN-Adresse**, nicht am offenen Internet.
- Wer das Passwort aus dem Git ziehen will, braucht ohnehin schon Zugriff auf dein
  privates Repository — und wäre damit bereits in deinem Netz.
- Das Rotieren ist bei selbst gehostetem Supabase **fehleranfällig**, weil dasselbe
  Passwort an mehreren Stellen steckt (siehe unten). Ein halb durchgeführter Wechsel
  legt die Datenbank lahm.

`NEXTAUTH_SECRET` (Schritt 1) und `SMTP_PASSWORD` (Schritt 3) sind die wichtigen —
das eine schützt die Sitzungen, das andere ist von außen missbrauchbar. Beide sind
erledigt. **Schritt 2 kannst du in Ruhe planen oder ganz auslassen.**

### Falls du es doch machst

Das Postgres-Passwort steckt bei einem Supabase-Docker-Stack an **mehreren** Stellen.
Es reicht nicht, es in Postgres zu ändern — die Supabase-Container kämen dann nicht
mehr an ihre eigene Datenbank.

Auf dem **Supabase-LXC**:

```bash
cd ~/supabase/docker          # Pfad ggf. anpassen

# 1. Sicherung, bevor irgendetwas angefasst wird
docker compose exec -T db pg_dumpall -U postgres > ~/supabase-backup-$(date +%F).sql
ls -lh ~/supabase-backup-*.sql

# 2. Neues Passwort erzeugen und direkt in die Supabase-Konfiguration schreiben
sed -i "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(openssl rand -base64 24 | tr -d '/+=')|" .env

# 3. Dasselbe Passwort in Postgres setzen
docker compose exec -T db psql -U postgres -c \
  "ALTER USER postgres WITH PASSWORD '$(grep '^POSTGRES_PASSWORD=' .env | cut -d= -f2-)';"

# 4. Stack neu starten, damit alle Dienste das neue Passwort bekommen
docker compose down && docker compose up -d
docker compose ps
```

Danach auf dem **App-Container** die beiden URLs anpassen — das neue Passwort aus
`supabase/docker/.env` einsetzen:

```bash
cd /root/My-Weekly-ToDo-List
read -rsp "Neue DATABASE_URL einfügen: " V && printf '\n' && \
  sed -i "s|^DATABASE_URL=.*|DATABASE_URL=\"$V\"|" .env && unset V

read -rsp "Neue DIRECT_URL einfügen: " V && printf '\n' && \
  sed -i "s|^DIRECT_URL=.*|DIRECT_URL=\"$V\"|" .env && unset V
```

Verbindung prüfen:

```bash
npx prisma db execute --stdin <<< "SELECT 1;" && echo "Datenbank erreichbar"
```

Wenn etwas schiefgeht: Der Dump aus Schritt 1 ist die Rückfahrkarte.

---

## Schritt 3 — SMTP-Passwort rotieren

1. Beim Mail-Anbieter ein neues Passwort setzen (idealerweise ein App-Passwort)
2. Auf dem Container eintragen:

```bash
cd /root/My-Weekly-ToDo-List
read -rsp "Neues SMTP-Passwort: " V && printf '\n' && \
  sed -i "s|^SMTP_PASSWORD=.*|SMTP_PASSWORD=\"$V\"|" .env && unset V
```

---

## Schritt 4 — Übernehmen

```bash
cd /root/My-Weekly-ToDo-List
cp .env .next/standalone/.env
pm2 restart my-weekly-todo --update-env
pm2 save
```

Der Kopierschritt ist nötig, weil der Standalone-Build seine eigene `.env` neben
`server.js` liest.

Danach: einmal im Browser neu anmelden. Dass du ausgeloggt wurdest, ist der **Beweis**,
dass das neue `NEXTAUTH_SECRET` greift.

---

## Schritt 5 — Die Datei aus dem Git entfernen

```bash
cd /root/My-Weekly-ToDo-List   # oder im Arbeitsrepo
git rm --cached .env.production.save
rm .env.production.save
```

`.gitignore` ergänzen:

```
.env*
!.env.example
```

Committen, pushen, fertig.

---

## Schritt 6 — Historie: umschreiben oder nicht?

Nach Schritt 5 ist die Datei aus dem *aktuellen* Stand verschwunden — in der **Historie**
steht sie weiterhin.

**Meine Empfehlung: Historie so lassen.** Begründung:

- Das Repository ist **privat** (geprüft).
- Nach den Schritten 1–3 sind die enthaltenen Werte **wertlos**, weil überall ersetzt.
- Historie umschreiben ändert jeden Commit-Hash. Alle Klone (dein Rechner, der Container,
  Gitea) müssten neu geholt werden, alte Tags zeigen ins Leere. Das Risiko übersteigt
  den Nutzen deutlich.

Rotieren schlägt Umschreiben: Ein rotiertes Geheimnis in der Historie ist harmlos, ein
nicht rotiertes bleibt auch nach dem Umschreiben in jedem existierenden Klon.

Falls du es trotzdem willst — nur bei Bedarf, mit vorherigem Voll-Backup:

```bash
git filter-repo --path .env.production.save --invert-paths
```

Danach `git push --force` auf **beide** Remotes, und jeder Klon muss neu erstellt werden.

---

## Kontrolle zum Schluss

```bash
cd /root/My-Weekly-ToDo-List
git ls-files | grep -E "^\.env" || echo "OK: keine .env-Datei mehr im Git"
grep -cE "^(NEXTAUTH_SECRET|DATABASE_URL|DIRECT_URL|SMTP_PASSWORD)=" .env
```

Die zweite Zeile muss `4` ergeben — vier gesetzte Schlüssel, ohne einen davon zu zeigen.

Zum Schluss die Sicherungen aufräumen:

```bash
shred -u .env.backup-* 2>/dev/null || rm -f .env.backup-*
```