Sicherheitslücken melden

So meldest du

Per E-Mail an rachimmustafakotili@gmail.com. Wenn du weisst oder vermutest, dass die Lücke bereits ausgenutzt wird, schreib das in die Betreffzeile — dafür gibt es eine gesetzliche 24-Stunden-Frist (siehe unten), und die Nachricht muss dann sofort auffallen.

Hilfreich in der Meldung:

• Was betroffen ist (URL, Version, Plattform).
• Wie man es nachstellt — kurz und Schritt für Schritt reicht.
• Was ein Angreifer damit erreichen könnte.
• Ob du vorhast zu veröffentlichen, und wann.

Es gibt derzeit keinen PGP-Schlüssel. Wenn eine Meldung verschlüsselt übertragen werden muss, schreib eine leere Mail mit dem Betreff „Kanal“ — dann wird einer vereinbart, bevor Einzelheiten fliessen. Maschinenlesbar steht derselbe Kontakt unter /.well-known/security.txt.

Was danach passiert

• Eingangsbestätigung innerhalb von 5 Werktagen. Kommt keine, ist die Mail vermutlich untergegangen — bitte noch einmal senden.
• Ersteinschätzung innerhalb von 10 Werktagen: nachvollzogen oder nicht, wie schwer, und ob daran gearbeitet wird.
• Danach mindestens alle 14 Tage eine Rückmeldung zum Stand, bis die Sache erledigt ist.
• Nach der Behebung: ein Hinweis im Changelog. Auf Wunsch mit Namensnennung — oder ausdrücklich ohne.

Das Projekt wird von einer einzelnen Person betrieben. Die Fristen sind deshalb bewusst nicht sportlich gewählt, sondern so, dass sie auch im Urlaub halten. Kürzer wäre eine schönere Zahl und eine schlechtere Zusage.

Veröffentlichung

Bitte gib uns 90 Tage ab deiner Meldung, bevor du Einzelheiten veröffentlichst. Ist vorher ein Update draussen, kannst du sofort veröffentlichen — dann ist niemand mehr geschützt, indem man schweigt.

Wenn die Behebung länger dauert, sagen wir das und nennen einen Grund; die Frist zu verlängern ist deine Entscheidung, nicht unsere. Wird eine Lücke bereits ausgenutzt, ziehen wir die Veröffentlichung von uns aus vor — dann wiegt die Warnung der Nutzer schwerer als die stille Behebung.

Zusage: gutgläubige Suche wird nicht verfolgt

Wer sich an diese Richtlinie hält, muss von uns weder zivilrechtliche noch strafrechtliche Schritte befürchten, und wir werden auch keine Dritten dazu auffordern. Wir betrachten solche Tests als befugt im Sinne von § 202a ff. StGB. Sollte jemand anderes wegen deiner Meldung an uns herantreten, sagen wir, dass die Untersuchung im Rahmen dieser Richtlinie erlaubt war.

Dazu gehört, dass du:

• nur mit eigenen Konten und eigenen Daten testest — nicht mit denen anderer Nutzer;
• fremde Daten, die dir zufällig zugänglich werden, nicht liest, speicherst oder weitergibst, sondern die Sache meldest und den Zugriff abbrichst;
• keine Denial-of-Service-Tests, kein Spam, kein Social Engineering gegen Personen und keine physischen Angriffe fährst;
• nichts zerstörst und keine Daten veränderst;
• die Frist oben einhältst.

Diese Zusage kann nur für uns selbst gelten. Wir können sie nicht für Dritte geben — siehe den nächsten Abschnitt.

Wofür das gilt

Dabei: diese Website, die installierbare App (auch die Store-Fassungen), der Synchronisierungs-Server und die Lizenzprüfung.

Nicht dabei — weil uns die Systeme nicht gehören und wir dort niemandem etwas zusagen können: Zahlungsabwicklung (Stripe), Analyse (PostHog), Fehlerberichte (Sentry), der Newsletter-Dienst und der Hoster. Findest du dort etwas, melde es bitte direkt beim jeweiligen Anbieter; wir helfen gern beim Weiterleiten.

Bekannt und bewusst so: Manches ist keine Lücke, sondern eine dokumentierte Abwägung — etwa dass die Schlüsselableitung im Browser mit Argon2id in der Stufe „interactive“ läuft (Rechenzeit auf schwachen Geräten gegen Widerstand beim Offline-Rateangriff), oder dass eine gekaufte Lizenz absichtlich an kein Konto gebunden und damit weitergebbar ist. Melde es trotzdem, wenn du glaubst, dass die Abwägung falsch getroffen ist — aber erwarte eine Begründung statt eines Patches.

Der Vollständigkeit halber der Punkt, den man beim Abklopfen zuerst findet: Die Registrierung am Synchronisierungs-Server antwortet unterschiedlich, je nachdem, ob zu einer E-Mail-Adresse schon ein Konto besteht. Das ist bekannt. Der Client muss es erfahren — sonst hielte jemand sein Konto für angelegt, während es das nicht ist, und in einer Anwendung, in der dein Schlüssel die einzige Kopie ist, wäre das der teurere Fehler. Über die Antwortzeit verrät sich nichts mehr, und die Registrierung ist auf drei Anfragen pro Stunde und IP begrenzt. Die Abwägung samt der Alternativen, die wir verworfen haben, steht offen im Quelltext (docs/decisions/0006-…). Anmelden ist ohnehin freiwillig: die App läuft vollständig ohne Konto.

Reine Scanner-Ausgaben ohne gezeigte Auswirkung (fehlende Header, Versionsnummern, „SPF/DMARC nicht optimal“) führen zu einer freundlichen, kurzen Antwort. Ein Geldbetrag wird nicht gezahlt — das Projekt hat kein Bug-Bounty-Budget, und das vorher zu sagen ist ehrlicher, als es hinterher zu erklären.

Was wir an Behörden weitergeben müssen

Ab dem 11. September 2026 verpflichtet Artikel 14 der EU-Verordnung 2024/2847 (Cyber Resilience Act) Hersteller dazu, eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden nach Kenntniserlangung an die ENISA und das zuständige nationale CSIRT zu melden — mit einer genaueren Meldung nach 72 Stunden und einem Abschlussbericht, sobald eine Gegenmassnahme verfügbar ist.

Das betrifft die Lücke, nicht dich: In diesen Meldungen steht, was betroffen ist und was dagegen getan wird. Deinen Namen geben wir dabei nicht weiter, ausser du willst es ausdrücklich.