Vorstellung von donate ― einem selbstgehosteten Spendenservice für Aufgaben

Merkmale:

• KISS;
• selbstgehostet;
• Fehlen von Gebühren (zum Beispiel, Bountysource und Gitcoin ziehen sich 10% von der Auszahlung ab);
• Unterstützung mehrerer Kryptowährungen (aktuell Bitcoin, Ethereum und Cardano);
• Geplant (und vorgesehen) ist die Unterstützung von GitLab, Gitea und anderen Git-Hosting-Diensten in Zukunft.
• Globale Aufgabenliste von allen (d.h. einem zum Zeitpunkt der Nachrichtenverfassung) Instanzen auf donate.dumpstack.io.

Arbeitsmechanismus für GitHub aus Sicht des Repository-Besitzers:

• (optional) es ist erforderlich, den Dienst zu implementieren, es kann verwendet werden eine fertige Konfiguration für NixOS;
• es muss hinzugefügt werden GitHub Action — innerhalb wird ein Dienstprogramm aufgerufen, das die Aufgaben des Projekts scannt und einen Kommentar über den aktuellen Status der Spenden-Wallets hinzufügt/aktualisiert, wobei der private Teil der Wallets nur auf dem Spenden-Server gespeichert wird (in Zukunft mit der Möglichkeit, dies offline für große Spenden zu ermöglichen, zur manuellen Bestätigung der Auszahlung);
• in allen aktuellen Aufgaben (und neuen) erscheint eine Nachricht von github-actions[bot] mit den Adressen der Spenden-Wallets (Beispiel).

Arbeitsmechanismus aus Sicht des ausführenden Aufgaben:

• im Kommentar zum Commit wird angegeben, welche spezifische Aufgabe dieser Commit löst (siehe Closing issues using keywords);
• im Text des Pull Requests werden die Adressen der Wallets in einem bestimmten Format angegeben (zum Beispiel, BTC{address}).
• bei Annahme des Pull Requests erfolgt die Auszahlung automatisch.
• wenn die Wallets nicht angegeben sind oder nicht alle angegeben sind, erfolgt die Auszahlung der Mittel für nicht angegebene Wallets an die Standard-Wallets (zum Beispiel kann dies eine gemeinsame Projekt-Wallet sein).

Sicherheit:

• Die Angriffsfläche ist insgesamt gering;
• basierend auf den Arbeitsmechanismen sollte der Dienst in der Lage sein, Mittel eigenständig zu versenden, so dass der Zugang zum Server in jedem Fall Kontrolle über die Mittel bedeutet — die einzige Lösung könnte die Arbeit im nicht automatisierten Modus sein (zum Beispiel manuelle Bestätigung von Auszahlungen), die wahrscheinlich (wenn das Projekt erfolgreich genug ist, damit jemand auf diese Funktionalität spenden kann, dann ist es nicht wahrscheinlich, sondern sicher) irgendwann implementiert werden wird;
• kritisch wichtige Teile sind klar getrennt (in der Regel handelt es sich um die einzige Datei pay.go mit 200 Zeilen), was die Sicherheitscode-Überprüfung vereinfacht;
• Der Code hat eine unabhängige Sicherheitsüberprüfung bestanden, was nicht bedeutet, dass es keine Schwachstellen gibt, aber die Wahrscheinlichkeit ihres Vorhandenseins verringert, insbesondere im Hinblick auf die geplante regelmäßige Überprüfung;
• Es gibt auch Teile, die nicht kontrolliert werden (zum Beispiel die APIs von GitHub/GitLab usw.), mögliche Schwachstellen in externen APIs sollen durch zusätzliche Prüfungen geschlossen werden; dennoch ist das Problem im aktuellen Ökosystem insgesamt nicht lösbar und liegt außerhalb des Anwendungsbereichs (eine mögliche Schwachstelle, die es erlaubt, fremde Pull-Requests zu schließen und somit Code in fremde Projekte einzufügen - hat viel weitreichendere Folgen).

Quelle: linux.org.ru