Zaproponowano donate ― samodzielnie hostowaną usługę darowizn na cele


Zaproponowano donate ― samodzielnie hostowaną usługę darowizn na cele

Cechy:

  • KISS;
  • samo-hostowane;
  • brak opłat (na przykład, bountysource i gitcoin pobierają 10% z wypłaty);
  • wsparcie dla wielu kryptowalut (obecnie Bitcoin, Ethereum i Cardano);
  • przewiduje się (i jest przewidziane) wsparcie dla GitLab, Gitea oraz innych hostów Git w przyszłości.
  • globalna lista zadań ze wszystkich (to znaczy z jednego, w momencie pisania wiadomości) instancji na donate.dumpstack.io.

Mechanizm działania dla GitHub ze strony właściciela repozytorium:

  • (opcjonalnie) należy wdrożyć serwis, można użyć gotowej konfiguracji dla NixOS;
  • należy dodać GitHub Action — wewnątrz wywoływana jest aplikacja, która skanuje zadania projektu i dodaje/aktualizuje komentarz o bieżącym stanie portfeli do darowizn, przy czym prywatna część portfeli jest przechowywana tylko na serwerze darowizn (w przyszłości z możliwością przeniesienia do offline dla dużych darowizn, w celu ręcznego potwierdzenia wypłaty);
  • we wszystkich bieżących zadaniach (i nowych) pojawia się wiadomość od github-actions[bot] z adresami portfeli do darowizn (przykład).

Mechanizm działania ze strony wykonującego zadanie:

  • w komentarzu do commita wskazuje się, które konkretne zadanie ten commit rozwiązuje (patrz. zamykanie zadań przy użyciu słów kluczowych);
  • w treści pull requesta wskazuje się adresy portfeli w określonym formacie (na przykład, BTC{address}).
  • przy akceptacji pull requesta wypłata dokonuje się automatycznie.
  • jeśli portfele nie są wskazane, lub nie są wskazane wszystkie, to wypłata dla niewskazanych portfeli odbywa się na portfele domyślne (na przykład, może to być wspólny portfel projektu).

Bezpieczeństwo:

  • powierzchnia ataku w całości jest niewielka;
  • biorąc pod uwagę mechanizmy działania, serwis powinien mieć możliwość samodzielnego wysyłania środków, więc uzyskanie dostępu do serwera oznaczałoby kontrolę nad środkami w każdym przypadku — rozwiązaniem może być jedynie działanie w trybie nieautomatycznym (na przykład, ręczne potwierdzanie wypłat), które prawdopodobnie (jeśli projekt będzie wystarczająco udany, aby ktoś sfinansował tę funkcjonalność, to nieprawdopodobne, a pewne) będzie kiedyś zrealizowane;
  • krytycznie ważne części są wyraźnie oddzielone (w zasadzie jest to jeden plik pay.go na 200 linii), co znacznie ułatwia przegląd bezpieczeństwa kodu;
  • Kod przeszedł niezależny przegląd bezpieczeństwa, co nie oznacza braku podatności, ale zmniejsza prawdopodobieństwo ich wystąpienia, szczególnie w świetle zaplanowanej regularności przeglądów;
  • Są też te części, które nie są kontrolowane (na przykład API GitHub/GitLab/etc.), przy czym ewentualne podatności zewnętrznego API planuje się zamykać dodatkowymi kontrolami, niemniej jednak problem w obecnej ekosystemie pozostaje nierozwiązany i wykracza poza zakres (potencjalna podatność na przykład z możliwością zamykania cudzych pull requestów i tym samym dodawania kodu do cudzych projektów - ma znacznie bardziej globalne konsekwencje).

Źródło: linux.org.ru

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster