contribution-checker

Warum es das gibt

Beliebte Repositories ziehen Pull Requests an, um die niemand gebeten hat. Sie von Hand zu sichten ist langsam, und der langsame Teil ist nicht das Code-Review. Es ist die Entscheidung, ob der Beitrag überhaupt hätte eröffnet werden sollen.

contribution-checker zieht diese Entscheidung nach vorn. Beitragende bewerben sich über ein öffentliches Formular. Maintainer geben über ein Dashboard frei oder lehnen ab. Alles Weitere folgt aus dieser einen Entscheidung.

Wie es arbeitet

Eine GitHub-App beobachtet pull_request.opened und pull_request.reopened auf verknüpften Repositories. Ist die verfassende Person für dieses Projekt nicht freigegeben, schließt die App den Pull Request mit einem Kommentar, der auf die Bewerbungsseite des Projekts verweist. Gibt eine Maintainerin die Person frei, öffnen sich deren zuvor geschlossene Pull Requests über alle verknüpften Repositories hinweg automatisch wieder.

Für Repositories, in denen sich keine GitHub-App installieren lässt, gibt es einen zweiten Weg. Zwei GitHub-Actions-Workflows leisten dieselbe Sperre aus Actions heraus und authentifizieren sich mit dem OIDC-Token des Laufs. Nichts wird geteilt, es gibt also kein Geheimnis zu konfigurieren oder zu rotieren.

Die Freigabe ist nicht der einzige Weg an der Sperre vorbei. Eine manuelle Entscheidung zu einem GitHub-Login gewinnt zuerst, dann die Ausnahmeliste, dann die Prüfung auf Mitarbeit am Repository, dann die letzte Bewerbung der Person. Diese Reihenfolge ist der Grund, warum Bots und bestehende Mitarbeitende das Formular nie sehen.

Was es abdeckt

Jedes Projekt baut sein eigenes Bewerbungsformular über einen Schema-Baukasten, und Formulare lassen sich als Vorlagen speichern und wiederverwenden. Der Zugang zu einem Projekt kommt in drei Rollen: Owner, Admin und Reviewer. Jede Entscheidung landet in einem nur anfügbaren Prüfprotokoll.

Maintainer werden in der Anwendung, per SMTP-E-Mail und über HMAC-signierte ausgehende Webhooks mit Wiederholungen benachrichtigt. Pull Requests bekommen projektbezogene Labels für offen, freigegeben und abgelehnt. Jeder GitHub-Login lässt sich ohne Bewerbung von Hand freigeben oder ablehnen, Bots lassen sich auf eine Ausnahmeliste setzen, Mitarbeitende eines Repositories lassen sich automatisch ausnehmen, Ablehnungen können eine Sperrfrist bis zur erneuten Bewerbung tragen, und der Entzug einer Freigabe kann die offenen Pull Requests dieser Person schließen.

Der öffentliche Bewerbungsendpunkt ist ratenbegrenzt.

Es betreibt sich selbst als Docker-Compose-Stack auf SQLite, mit Geheimnissen aus Umgebungsvariablen oder HashiCorp Vault.

Wo es steht

Es ist aus der Postiz-Arbeit entstanden, nicht aus GHub. Es ist öffentlich und unter AGPL lizenziert, lässt sich also außerhalb des Zusammenhangs lesen, betreiben und forken, für den es geschrieben wurde.

Ein Umzug zu GHub steht im Raum. Er ist nicht geschehen, und dieser Eintrag wird es sagen, wenn es so weit ist.

Umfang

Es sperrt Pull Requests und verwaltet die Bewerbungen hinter dieser Sperre.

Es beurteilt den Beitrag nicht. Es hält fest, wer einen eröffnen darf.

Es wird am selben Maßstab gemessen wie alles andere

Contribution Checker hat eigene veröffentlichte Advisories, unter dem Präfix GSSA- auf gadvisory.org, aufgeschrieben so, wie ein Fund von außen aufgeschrieben würde.

Sie betreffen das, was ein Dashboard falsch macht, wenn niemand hinsieht: ohne Content Security Policy, Frame Options und HSTS auszuliefern, und auf den Webhook- und CI-Endpunkten einen vollständigen Request-Body zu lesen, bevor irgendetwas geprüft wird — womit ein Post von mehreren Gigabyte den Prozessspeicher erschöpfen konnte. Beides ist behoben, und beides steht im Bestand.

Die eigenen Funde gegen das eigene Produkt zu veröffentlichen ist die billige Fassung eines Versprechens. Es kostet etwas Stolz und sorgt dafür, dass die Sicherheitsseite nicht die einzige Stelle ist, die Behauptungen aufstellt.