Security-Review führt Tests in der Sandbox aus, auch mit PostgreSQL (#37)

[Musiker15]

Teil von #37. Das Issue schließt, wenn die Aufrufe der fünf Repositories auf den gemergten Commit zeigen.

Was sich ändert

Das Security-Review kann jetzt Tests ausführen, auch solche mit Datenbank. Der Probelauf hat gezeigt, dass es das bisher gar nicht konnte: in seiner Sandbox ließ sich nichts installieren, mit oder ohne Datenbank. Vier Dinge fehlten, und alle vier bringt dieser Pull Request.

• Datenbank. Der Aufruf nennt die Testdatenbank des Repositorys: with: database: postgres://Rolle:Passwort@127.0.0.1:Port/Name. PostgreSQL 18 kommt aus der Paketquelle von PostgreSQL, solange es sudo gibt: nur die Programme, kein Cluster, kein Dienst, der Schlüssel der Quelle gegen seinen Fingerabdruck geprüft. Den Server startet das Review selbst in der Sandbox mit with-database <Befehl>: über TCP auf dem 127.0.0.1 der Sandbox, mit den Daten unter .security-review/cache, für die Dauer eines Befehls.
• Registry. Corepack liest die Proxy-Variablen der Sandbox nicht von selbst und suchte die Registry direkt (getaddrinfo EAI_AGAIN). NODE_USE_ENV_PROXY=1 lässt Node den Proxy benutzen.
• pnpm im Pfad. corepack enable wie in der CI, denn turbo findet pnpm hinter corepack pnpm nicht.
• Arbeitskopie. Mit CLAUDE_CODE_SUBPROCESS_ENV_SCRUB hält die Sandbox im Arbeitsverzeichnis package.json, die Lockfiles, node_modules/.bin, scripts und .github schreibgeschützt, damit kein späterer Schritt ausführt, was der Agent dort abgelegt hat. Das bleibt so. Für Tests legt review-workspace beim ersten Aufruf eine Kopie dessen an, was git im Checkout kennt, unter .security-review/cache. Sie entsteht in der Sandbox und verschwindet mit dem Checkout.

Dazu der Auftrag: Ändert ein Pull Request etwas, das erst die Datenbank durchsetzt (Policy, Trigger, Recht einer Rolle, Constraint, Migration), oder stützt sich neuer Code darauf, wird der Beleg ausgeführt und nicht nur gelesen, mit einzelnen Testdateien oder einem eigenen Gegenversuch. Die ganze Testreihe bleibt Sache der CI. Der Bericht nennt, was mit der Datenbank lief. Startet sie nicht, ist das kein Befund.

Was gleich bleibt

• Die Einstellungen der Sandbox sind unverändert: Netz nur zur npm-Registry, dieselben Sperren für Lesen und Schreiben, dieselben entfernten Variablen, dieselben erlaubten Werkzeuge.
• sudo und Docker sind beim Review abgeschaltet wie bisher. Neu geprüft wird im selben Schritt, dass außerhalb der Sandbox kein PostgreSQL läuft; sonst läuft das Review nicht.
• Ohne die Eingabe database bekommt ein Repository keine Datenbank. Ein Pull Request von außen bekommt weiterhin keine Shell und damit nichts von alldem.
• Schlägt die Installation fehl oder ist die Angabe nicht lesbar, läuft das Review ohne Datenbank weiter.

Abschalten

Die Variable SECURITY_REVIEW_DATABASE der Organisation, auf aus gesetzt, nimmt die Datenbank für alle Repositories heraus, ohne Pull Request. Der Stand vor dieser Änderung liegt als Zweig sicherung/security-review-ohne-datenbank auf 450efc1; auf diesen Commit zeigen die fünf Aufrufe heute.

Geprüft

Lokal in einem Container mit Ubuntu 24.04, bubblewrap und der Sandbox-Laufzeit, mit den Schritten, wie sie im Workflow stehen: Unix-Sockets gesperrt, Netz nur zur Registry, Schreiben außerhalb verweigert; darin Server starten, Daten zwischen zwei Befehlen, ein hart beendeter Helfer, zwei Aufrufe zugleich, sieben unzulässige Angaben der Adresse, und die ganze Kette aus Kopie, Installation, Bau und einer Testdatei gegen die Datenbank.

Auf dem Runner mit vier Probeläufen an opengewerk/opengewerk-haustechnik#249, der den Diff von opengewerk/opengewerk-haustechnik#248 noch einmal prüft:

Lauf	Stand	Kosten	Züge	Dauer	Mit Datenbank ausgeführt
#248 im Original	ohne Datenbank	0,167 USD	11	78 s	nichts, "nur statisch geprüft"
Probe 1	Datenbank, Auftrag zurückhaltend	0,208 USD	12	111 s	nichts, alles lesend entschieden
Probe 2	Auftrag geschärft	0,149 USD	10	88 s	nichts, Installation scheitert am Proxy
Probe 3	Proxy und pnpm im Pfad	0,175 USD	9	112 s	nichts, node_modules/.bin schreibgeschützt
Probe 4	Arbeitskopie	0,193 USD	13	122 s	3 Testdateien, 47 Tests, alle grün

Die letzten 14 Reviews der Haustechnik lagen zwischen 0,11 und 0,29 USD. Probe 4 liegt mitten darin: die Tests kosten Laufzeit auf dem Runner, aber kaum Züge. Die Installation von PostgreSQL braucht 6 bis 9 Sekunden je Lauf.

Eigene Festlegungen, die Moritz noch nicht gesehen hat

• Die Eingabe ist eine Adresse, also eine Datenbank je Repository. Die CI der Haustechnik hat zwei, aber nur, damit zwei Testreihen nebeneinander laufen.
• Der Cluster wird mit C.UTF-8 angelegt: Byte-Reihenfolge, wie das Abbild postgres:18-alpine der CI sortiert. fsync ist aus, nichts dort überlebt den Lauf.
• Tests laufen in einer Kopie statt im Checkout. Die Alternative wäre gewesen, die Härtung der Sandbox zu lockern.
• NODE_USE_ENV_PROXY, corepack enable und die Arbeitskopie gelten für jedes Review mit Shell, auch ohne Datenbank: ohne sie lässt sich in keinem Repository etwas installieren.
• Der Schalter ist eine Variable der Organisation und heißt SECURITY_REVIEW_DATABASE.

Danach

Die Aufrufe der fünf Repositories werden auf den gemergten Commit angehoben, in der Haustechnik und in der Handwerkersoftware mit der Eingabe database.