Funksjoner:
- KYSSE;
- selv-vert;
- ingen gebyrer (for eksempel bountysource og gitcoin tar 10 % av betalingen);
- støtte for mange kryptovalutaer (for tiden Bitcoin, Ethereum og Cardano);
- det forventes (og leveres) å støtte GitLab, Gitea og andre Git-vertstjenester i fremtiden.
- global liste over oppgaver fra alle (det vil si én, på tidspunktet for skriving av nyhetene) forekomster på donate.dumpstack.io.
Arbeidsmekanismen for GitHub fra siden til depoteieren:
- (valgfritt) du trenger for å distribuere tjenesten, kan du bruke ferdig konfigurasjon for NixOS;
- må legges til GitHub-handling — et verktøy kalles på innsiden som skanner prosjektets oppgaver og legger til/oppdaterer en kommentar om den nåværende tilstanden til donasjonslommebøker, mens den private delen av lommeboken lagres kun på donasjonsserveren (i fremtiden, med mulighet til å ta den offline for store donasjoner, for manuell bekreftelse av betaling);
- i alle aktuelle oppgaver (og nye) kommer det en melding fra github-actions[bot] med lommebokadresser for donasjoner (eksempel).
Arbeidsmekanismen til personen som utfører oppgaven:
- kommentaren til commit indikerer nøyaktig hvilket problem denne commit løser (se. lukke problemer ved å bruke søkeord);
- hoveddelen av pull-forespørselen spesifiserer lommebokadresser i et spesifikt format (f.eks. BTC{adresse}).
- Når en pull-forespørsel er akseptert, utføres betalingen automatisk.
- hvis lommebokene ikke er spesifisert, eller ikke alle er spesifisert, vil betalingen av midler for de uspesifiserte lommebøkene gjøres til standard lommebøker (for eksempel kan dette være en generell prosjektlommebok).
sikkerhet:
- angrepsflaten er generelt liten;
- Basert på driftsmekanismene skal tjenesten kunne sende midler uavhengig, så å få tilgang til serveren vil uansett bety kontroll over midlene - løsningen kan bare være å jobbe i en ikke-automatisert modus (for eksempel bekreftelse betalinger manuelt), som er sannsynlig (hvis prosjektet er vellykket nok til at noen kan donere for denne funksjonaliteten, så er det ikke sannsynlig, men definitivt) at det vil bli implementert en dag;
- kritiske deler er tydelig atskilt (faktisk er dette en enkelt pay.go-fil på 200 linjer), og forenkler dermed gjennomgang av sikkerhetskode;
- koden har bestått en uavhengig sikkerhetskodegjennomgang, som ikke betyr fravær av sårbarheter, men reduserer sannsynligheten for deres tilstedeværelse, spesielt i lys av den planlagte regelmessigheten av anmeldelser;
- det er også de delene som ikke er kontrollert (for eksempel API GitHub/GitLab/etc.), mens mulige sårbarheter i tredjeparts API er planlagt lukket med ytterligere kontroller, men generelt er problemet i gjeldende økosystem er uløselig og utenfor scope (mulig sårbarhet med for eksempel muligheten til å lukke andres pull-forespørsler og dermed legge kode til andres prosjekter – har mye mer globale konsekvenser).
Kilde: linux.org.ru