Egenskaber:
- KISS;
- self-hosted;
- ingen gebyrer (for eksempel, bountysource og gitcoin tager 10% af udbetalingen);
- support for mange kryptovalutaer (i øjeblikket Bitcoin, Ethereum og Cardano);
- det forventes (og er planlagt) at inkludere support for GitLab, Gitea og andre Git-hostingtjenester i fremtiden.
- en global liste over opgaver fra alle (eller rettere, én, på tidspunktet for denne nyhed) instanser på donate.dumpstack.io.
Funktionsmekanismen for GitHub fra ejerens side:
- (valgfrit) det er nødvendigt at implementere tjenesten, man kan bruge den færdige konfiguration til NixOS;
- det er nødvendigt at tilføje GitHub Action — indeni kaldes et værktøj, der scanner projektopgaver og tilføjer/opdaterer kommentaren om den aktuelle tilstand af donationswallets, mens den private del af wallets kun opbevares på donationsserveren (i fremtiden med mulighed for at tage det offline for større donationer, til manuel bekræftelse af betaling);
- i alle aktuelle opgaver (og nye) vises der en meddelelse fra github-actions[bot] med adresser til donationswallets (eksempel).
Funktionsmekanismen fra siden, der udfører opgaven:
- i kommentaren til commit angives, hvilken specifik opgave dette commit løser (se. closing issues using keywords);
- i teksten af pull request angives adresserne til wallets i et bestemt format (for eksempel, BTC{address}).
- ved accept af pull request foretages betalingen automatisk.
- hvis wallets ikke er angivet, eller ikke alle er angivet, så udbetales midlerne for de uoplyste wallets til standardwallets (for eksempel, dette kan være projektets fælles wallet).
Sikkerhed:
- angrebsoverfladen er generelt lille;
- baseret på funktionsmekanismerne, skal tjenesten have mulighed for at sende midler selv, så adgang til serveren vil betyde kontrol over midlerne uanset hvad – løsningen kan kun være at arbejde i ikke-automatiseret tilstand (for eksempel, manuel bekræftelse af betalinger), som sandsynligvis (hvis projektet skal blive tilstrækkeligt succesfuldt til, at nogen donerer til denne funktionalitet, så ikke sandsynligt, men helt sikkert) vil blive implementeret på et tidspunkt;
- kritiske dele er klart adskilt (læren er, det er i bund og grund den eneste fil pay.go på 200 linjer), hvilket dermed forenkler kodegennemgang for sikkerhed.
- Koden har gennemgået en uafhængig sikkerhedscodegennemgang, hvilket ikke betyder, at der ikke er sårbarheder, men det reducerer sandsynligheden for deres tilstedeværelse, især i lyset af den planlagte regelmæssighed af gennemgangene;
- Der er også dele, der ikke kontrolleres (for eksempel API'er som GitHub/GitLab/etc.), mens mulige sårbarheder i tredjeparts-API'er planlægges dækket af yderligere kontroller. Ikke desto mindre er problemet i det nuværende økosystem uopløseligt og uden for vores rækkevidde (en potentiel sårbarhed, som for eksempel muligheden for at lukke andres pull requests og dermed tilføje kode til andres projekter, har meget mere globale konsekvenser).
Kilde: linux.org.ru
