Donate präsentiert – ein selbstgehosteter Spendenservice für Projekte

Besonderheiten:

• KISS;
• selbstgehostet;
• keine Gebühren (zum Beispiel, Bountysource und Gitcoin behalten 10 % der Auszahlung);
• Unterstützung mehrerer Kryptowährungen (derzeit Bitcoin, Ethereum und Cardano);
• Die Unterstützung für GitLab, Gitea und andere Git-Hosting-Dienste ist vorgesehen und wird in Zukunft realisiert.
• Eine globale Aufgabenliste von allen (also einer, zum Zeitpunkt der Nachrichtenveröffentlichung) Instanzen auf donate.dumpstack.io.

So funktioniert es für GitHub vom Seiten des Repository-Besitzers:

• (optional) Der Dienst muss bereitgestellt werden, eine bereits vorbereitete Konfiguration für NixOS kann verwendet werden.;
• Es ist notwendig, GitHub Action hinzuzufügen – darin wird ein Dienstprogramm aufgerufen, das die Aufgaben des Projekts scannt und einen Kommentar über den aktuellen Zustand der Spendenbrieftaschen hinzufügt/aktualisiert, wobei der private Teil der Brieftaschen ausschließlich auf dem Spendenserver gespeichert wird (in Zukunft mit der Möglichkeit, für größere Spenden offline zu gehen, um die Auszahlung manuell zu bestätigen);
• In allen aktuellen Aufgaben (und neuen) erscheint eine Nachricht von github-actions[bot] mit den Adressen der Spendenbrieftaschen (Nummer 00 oder).

So funktioniert es vom Standpunkt des Ausführenden der Aufgabe:

• Im Kommentar zum Commit wird angegeben, welche Aufgabe dieser Commit konkret löst (siehe. Schließen von Issues mit Schlüsselwörtern.);
• Im Text des Pull Requests werden die Wallet-Adressen in einem bestimmten Format angegeben (zum Beispiel. BTC{address}.).
• Bei der Annahme des Pull Requests erfolgt die Auszahlung automatisch.
• Wenn keine Wallets angegeben sind oder nicht alle angegeben werden, erfolgt die Zahlung für nicht angegebene Wallets an die Standard-Wallets (zum Beispiel kann dies die allgemeine Wallet des Projekts sein).

Sicherheit:

• Die Angriffsfläche ist insgesamt gering.
• Basierend auf der Funktionsweise muss der Dienst in der Lage sein, selbstständig Gelder zu senden, sodass der Zugriff auf den Server in jedem Fall die Kontrolle über die Gelder bedeutet – die einzige Lösung könnte nur die manuelle Arbeitsweise sein (zum Beispiel die manuelle Bestätigung von Auszahlungen), was wahrscheinlich (wenn das Projekt genug Erfolg hat, damit jemand für diese Funktionalität spendet, dann nicht wahrscheinlich, sondern sicher) irgendwann umgesetzt wird.
• Kritische Teile sind eindeutig getrennt (es handelt sich im Wesentlichen um eine einzige Datei pay.go mit 200 Zeilen), wodurch die Sicherheitsüberprüfung des Codes vereinfacht wird.
• Der Code hat eine unabhängige Sicherheitsprüfung bestanden, was jedoch nicht bedeutet, dass keine Schwachstellen vorhanden sind. Es verringert jedoch die Wahrscheinlichkeit, 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/etc.), wobei mögliche Schwachstellen in diesen externen APIs durch zusätzliche Überprüfungen geschlossen werden sollen. Dennoch ist das Problem in der aktuellen Ökosystem insgesamt nicht lösbar und fällt außerhalb des Geltungsbereichs (eine potenzielle Schwachstelle, die es ermöglicht, fremde Pull-Requests zu schließen und dadurch Code in fremde Projekte einzufügen, hat viel weitreichendere Folgen).

Quelle: linux.org.ru