Introduced donate - un serviciu de donații auto-găzduit pentru sarcini


Introduced donate - un serviciu de donații auto-găzduit pentru sarcini

Caracteristici:

  • PUP;
  • auto-găzduit;
  • fără taxe (de exemplu, bountysource și gitcoin iau 10% din plată);
  • suport pentru multe criptomonede (în prezent Bitcoin, Ethereum și Cardano);
  • este de așteptat (și furnizat) să suporte GitLab, Gitea și alte servicii de găzduire Git în viitor.
  • listă globală de sarcini din toate (adică una, la momentul scrierii știrilor) instanțe donate.dumpstack.io.

Mecanismul de lucru pentru GitHub din partea proprietarului depozitului:

  • (opțional) trebuie să implementați serviciul, puteți utiliza configurație gata făcută pentru NixOS;
  • trebuie adăugată Acțiune GitHub — se numește în interior un utilitar care scanează sarcinile proiectului și adaugă/actualizează un comentariu despre starea actuală a portofelelor de donații, în timp ce partea privată a portofelelor este stocată doar pe serverul de donații (în viitor, cu posibilitatea de a o prelua offline pentru donații mari, pentru confirmarea manuală a plății);
  • în toate sarcinile curente (și în cele noi) apare un mesaj de la github-actions[bot] cu adrese de portofel pentru donații (exemplu).

Mecanismul de lucru din partea persoanei care îndeplinește sarcina:

  • comentariul la commit indică exact ce problemă rezolvă acest commit (vezi. închiderea problemelor folosind cuvinte cheie);
  • corpul cererii de extragere specifică adresele portofelului într-un format specific (de exemplu, BTC{adresa}).
  • Când o solicitare pull este acceptată, plata se face automat.
  • dacă portofelele nu sunt specificate sau nu sunt specificate toate, atunci plata fondurilor pentru portofelele nespecificate se face către portofelele implicite (de exemplu, acesta ar putea fi un portofel de proiect general).

Securitate:

  • suprafata de atac este in general mica;
  • Pe baza mecanismelor de operare, serviciul ar trebui să poată trimite fonduri în mod independent, astfel încât obținerea accesului la server va însemna control asupra fondurilor în orice caz - soluția poate fi doar să funcționeze într-un mod neautomat (de exemplu, confirmarea plăți manual), ceea ce este probabil (dacă proiectul are suficient succes pentru ca cineva să doneze pentru această funcționalitate, atunci nu este probabil, dar cu siguranță) să fie implementat într-o zi;
  • părțile critice sunt clar separate (de fapt, acesta este un singur fișier pay.go de 200 de linii), simplificând astfel revizuirea codului de securitate;
  • codul a trecut o revizuire independentă a codului de securitate, ceea ce nu înseamnă absența vulnerabilităților, ci reduce probabilitatea prezenței acestora, mai ales în lumina regularității planificate a revizuirilor;
  • există și acele părți care nu sunt controlate (de exemplu, API GitHub/GitLab/etc.), în timp ce posibilele vulnerabilități din API-ul terță parte sunt planificate să fie închise cu verificări suplimentare, cu toate acestea, în general, problema în actualul ecosistemul este de nerezolvat și în afara domeniului de aplicare (posibila vulnerabilitate cu, de exemplu, capacitatea de a închide cererile de atragere ale altor persoane și, prin urmare, de a adăuga cod la proiectele altor persoane - are consecințe mult mai globale).

Sursa: linux.org.ru

Adauga un comentariu