GOpenCSR-Sicherheits- und Offenlegungsrichtlinie

Wie diese Richtlinie zu der von Gelhaus Solutions steht

GOpenCSR fällt unter die Richtlinie zur Offenlegung von Schwachstellen von Gelhaus Solutions, und alles darin gilt auch hier: wie Sie melden, die Reaktionszeiten, der sichere Hafen, Nennung und Kennungen. Diese Seite ergänzt, was für GOpenCSR besonders ist: was abgedeckt ist, was am meisten zählt und was ein Test nie tun darf. GOpenCSR meldet Menschen bei GOpenCDR, GOpenCNR und bei sich selbst an, gibt die Änderungen von Tier 0 frei, betreibt die Räte und führt das eine Transparenzlog. Ein Fehler hier trifft deshalb alle drei Dienste, und auf sie verlassen sich Menschen, die nie zugestimmt haben, Teil eines Tests zu sein.

GOpenCSR gehört zum Geltungsbereich des CVE-Numbering-Authority-Programms von Gelhaus Solutions, mit voller Abdeckung, und Kennungen werden vergeben, wie es die Offenlegungsrichtlinie beschreibt.

Wie Sie melden

Schreiben Sie an contact@gplatform.org oder reichen Sie die Meldung über GAdvisory ein. Beide Wege setzen dasselbe Verfahren in Gang. Verschlüsseln Sie alles Heikle mit dem Schlüssel, dessen Fingerabdruck in der Offenlegungsrichtlinie steht. Bitte eröffnen Sie kein öffentliches Issue.

Schreiben Sie „GOpenCSR“ in den Betreff und zusätzlich „dringend“, wenn die Meldung die Anmeldung, Freigaben nach dem Vier-Augen-Prinzip, das Transparenzlog oder einen Signierschlüssel betrifft. Solche Meldungen werden zuerst gelesen.

Die security.txt von GOpenCSR unter https://csr.gplatform.org/.well-known/security.txt verweist auf diese Seite, ebenso die Fußzeile jeder GOpenCSR-Seite.

Was abgedeckt ist

• Das Portal unter csr.gplatform.org und der zentrale API-Zugang unter csr.gplatform.org/api/{cdr,cnr,csr}/v1 mit seinen API-Schlüsseln.
• Die Anmeldung und der OpenID-Connect-Anbieter, über den GOpenCDR und GOpenCNR Menschen anmelden: Passwörter, Passkeys, Wiederherstellung, Sitzungen und Token.
• Step-up und der Signierschritt, einschließlich der Automatisierungsschlüssel, die unter einem Passkey hinterlegt sind.
• Freigaben nach dem Vier-Augen-Prinzip und der Einzelmodus.
• Die Mechanik der Räte und Anträge: Sitze, Stimmzettel, Unterstützungsstimmen und ihre Vertraulichkeit, vertrauliche Anträge und vertrauliche Stimmabgaben, Community-Anträge und Petitionen sowie der Gemeinsame Rat.
• Fälle, die Sanktionslistenprüfung und ihre Sperren sowie die Missbrauchs-Weiterleitungsadressen unter relay.csr.gplatform.org.
• Zielgruppen (Audiences).
• Zustimmungsnachweise.
• Das Transparenzlog unter csr.gplatform.org/tlog, seine Prüfpunkte, das Werkzeug, das es prüft, und seine Zeugen.
• Der gemeinsame Code, den GOpenCSR für die anderen Dienste veröffentlicht: die Agent-Kernbibliothek, auf der die Agenten von GOpenCNR und der Mirror-Agent von GOpenCDR aufbauen, und die Identitäts- und Richtlinien-Clients.

Worüber wir am liebsten hören

1. Jeden Weg in das Konto eines anderen: über die Anmeldung, die Wiederherstellung, Passkeys, Sitzungen oder den OpenID-Connect-Ablauf, einschließlich jedes Wegs, GOpenCDR oder GOpenCNR einen Code oder ein Token annehmen zu lassen, das für jemand anderen oder für einen anderen Dienst ausgestellt wurde.
2. Jeden Weg um Step-up oder den Signierschritt herum: zu handeln, wo ein frischer Passkey verlangt ist, ohne einen zu haben, oder eine Änderung signieren zu lassen, die von dem abweicht, was der Signierschritt gezeigt hat.
3. Jeden Weg, einen eigenen Antrag im Vier-Augen-Prinzip selbst freizugeben, eine Änderung von Tier 0 ohne die nötige Freigabe durchzubringen oder eine allein erteilte Freigabe ohne ihre Kennzeichnung „allein entschieden“ erscheinen zu lassen.
4. Jeden Weg, das Transparenzlog unterschiedlichen Menschen unterschiedliche Geschichten zeigen zu lassen oder eine Prüfung einen Eintrag oder Prüfpunkt annehmen zu lassen, den sie ablehnen müsste.
5. Jeden Weg, aus den gesalzenen Hashes im Log oder aus irgendetwas anderem, das GOpenCSR zeigt, die Mitglieder einer Zielgruppe oder einen Netzendpunkt zu erfahren, oder als Mitglied einer Zielgruppe zu erfahren, wer sonst darin ist.
6. Jeden Weg, einen vertraulichen Antrag, eine versiegelte Stimme oder den Namen eines Unterstützenden vor der nächsten Sitzung des Rats zu lesen.
7. Jeden Weg, einem API-Schlüssel Berechtigungen von Tier 0 zu verschaffen, ihn über eine Freigabe entscheiden oder Schlüssel verwalten zu lassen.
8. Jeden Weg, eine in einem Produkt erworbene Berechtigung bei den Sitzen, Stimmen, Kandidaturen, Befürwortungen oder Petitionen eines anderen Produkts zählen zu lassen.
9. Jeden Weg, über eine Missbrauchs-Weiterleitungsadresse die echte Adresse eines Inhabers zu erfahren oder einen Inhaber auf andere Weise zu enttarnen.
10. Jeden Weg, auf dem jemand außer dem Inhaber und Tier 0 erfährt, dass eine Sanktionslistenprüfung läuft, oder den bürgerlichen Namen und das Land eines Inhabers oder ein Prüfergebnis sieht, das sich einem Inhaber zuordnen lässt.

Regeln für Tests

GOpenCSR dient Menschen, die nie zugestimmt haben, dass an ihnen getestet wird, und vieles, was es festhält, ist öffentlich und dauerhaft. Deshalb gelten hier eigene Regeln, zusätzlich zu denen der Offenlegungsrichtlinie.

• Testen Sie nur mit Ihren eigenen Konten, Ihren eigenen Inhabern und Ihren eigenen Ressourcen.
• Keine Dienstverweigerung. Führen Sie keine Lasttests durch, fluten Sie nichts und versuchen Sie nicht, das Portal, den zentralen API-Zugang, die Anmeldung, das Transparenzlog oder die Missbrauchs-Weiterleitung zu erschöpfen, und legen Sie keine Konten in großer Zahl an.
• Testen Sie nicht an Konten, Inhabern, Ressourcen, Zielgruppen, Fällen oder Missbrauchs-Weiterleitungsadressen anderer Mitglieder, und senden Sie keine Test-E-Mails an die Missbrauchs-Weiterleitungsadresse eines anderen Inhabers.
• Denken Sie daran, was sich nicht zurücknehmen lässt. Eine signierte Änderung oder ein Stimmzettel, den Sie auslösen, steht dauerhaft im Transparenzlog, und eine Stellungnahme, ein Antrag oder eine Befürwortung in einem Rat ist öffentlich. Verwenden Sie davon nur so viel, wie Sie brauchen, um das Problem zu zeigen, und fragen Sie uns, bevor Sie etwas testen, das einen laufenden Rat erreichen würde.
• Greifen Sie nur auf das zu, was Sie brauchen, um das Problem zu zeigen. Erreichen Sie Daten anderer, hören Sie auf, behalten Sie nichts davon und sagen Sie es uns.
• Kein Social Engineering gegenüber unseren Mitarbeitenden, Ratsmitgliedern oder anderen Mitgliedern, keine physischen Angriffe und nichts, was auf unsere eigene Hardware zielt, einschließlich des Schlüsselspeichers und des Netzes dahinter.
• Behalten Sie die Einzelheiten bis zum abgestimmten Termin für sich.

Forschung innerhalb dieser Regeln ist willkommen, und der sichere Hafen der Offenlegungsrichtlinie deckt sie ab.

Was nicht abgedeckt ist

• Befunde in Software Dritter, die wir unverändert betreiben, etwa PostgreSQL, Temporal, HashiCorp Vault, Next.js, Tessera oder Stalwart. Melden Sie diese dem jeweiligen Projekt; wir helfen dabei und spielen die Korrektur ein.
• Befunde darin, was GOpenCDR oder GOpenCNR mit einer Anfrage tun, nachdem sie den zentralen API-Zugang passiert hat, und in den Programmen, die sie auf dem Agent-Kern aufbauen. Dafür gelten die GOpenCDR-Sicherheits- und Offenlegungsrichtlinie und die GOpenCNR-Sicherheits- und Offenlegungsrichtlinie. Wenn Sie nicht sicher sind, wohin ein Befund gehört, senden Sie ihn hierher; wir geben ihn weiter.
• Befunde, die ein bereits kompromittiertes Gerät, administrativen Zugang zu einem fremden Router, Hub oder Mirror oder ein Opfer voraussetzen, das etwas Ungewöhnliches installiert, es sei denn, GOpenCSR verschlimmert sie.
• Ausgaben automatischer Scanner ohne nachgewiesene Auswirkung, fehlende Header ohne Auswirkung und Ratenbegrenzungen, die wie beschrieben funktionieren.
• Missbrauch durch einen Inhaber, etwa Phishing unter einem Namen oder Scans von einer Adresse; dafür gilt abuse@gplatform.org nach der Richtlinie zu Missbrauch und Sanktionen.

Wenn ein Schlüssel kompromittiert sein könnte

Wenn Sie glauben, dass ein Schlüssel von GOpenCSR offengelegt sein könnte, etwa der Schlüssel für die Prüfpunkte des Transparenzlogs, der Schlüssel, der Anmeldetoken signiert, oder die Geheimnisse hinter API-Schlüsseln und Audit-Einträgen, schreiben Sie sofort, mit „Key“ im Betreff. Tier 0 kann nach seinem Notfallverfahren sofort handeln, das nur aussetzen oder verschärfen darf, nie lockern. Jede Notfallmaßnahme wird im Transparenzlog veröffentlicht und nachträglich überprüft.

Geht es um Ihren eigenen Passkey oder Automatisierungsschlüssel, entfernen Sie ihn sofort aus Ihrem Konto und sagen Sie uns, falls damit eine Änderung signiert wurde, die Sie nicht vorgenommen haben.

Probleme, die keine Schwachstellen sind

Eine fehlschlagende Anmeldung, ein Prüfpunkt, der nicht mehr vorrückt, ein Zeuge, der nicht mehr gegenzeichnet, oder eine E-Mail, die nie ankommt, ist nicht immer eine Schwachstelle, aber wir wollen ebenso schnell davon hören. Schreiben Sie an dieselbe Adresse.