Ominaisuudet:
- SUUDELLA;
- itse isännöivä;
- ei maksuja (esimerkiksi bountysource ja gitcoin ottavat 10% maksusta);
- tuki monille kryptovaluutoille (tällä hetkellä Bitcoin, Ethereum ja Cardano);
- GitLabin, Gitean ja muiden Git-isännöintipalvelujen tukea odotetaan (ja tarjotaan) tulevaisuudessa.
- maailmanlaajuinen luettelo tehtävistä kaikista (eli yhdestä uutisen kirjoittamishetkellä) esiintymistä donate.dumpstack.io.
GitHubin toimintamekanismi arkiston omistajan puolelta:
- (valinnainen) sinun on otettava palvelu käyttöön, voit käyttää sitä valmiit asetukset NixOS:lle;
- on lisättävä GitHub-toiminta — sisään kutsutaan apuohjelma, joka skannaa projektin tehtävät ja lisää/päivittää kommentin lahjoituslompakoiden nykytilasta, kun taas lompakoiden yksityinen osa tallennetaan vain lahjoituspalvelimelle (jatkossa mahdollisuus ottaa se vastaan offline suuria lahjoituksia varten, maksun manuaalista vahvistusta varten);
- kaikissa nykyisissä (ja uusissa) tehtävissä näkyy viesti github-toiminnot[bot] lompakkoosoitteita lahjoituksia varten (esimerkki).
Tehtävän suorittavan henkilön työmekanismi:
- Kommentti sitoumukseen osoittaa tarkalleen, minkä ongelman tämä sitoumus ratkaisee (katso. sulkemisongelmat avainsanojen avulla);
- vetopyynnön runko määrittää lompakon osoitteet tietyssä muodossa (esim. BTC{osoite}).
- Kun vetopyyntö hyväksytään, maksu suoritetaan automaattisesti.
- jos lompakoita ei ole määritetty tai kaikkia ei ole määritetty, määrittämättömien lompakoiden varojen maksu suoritetaan oletuslompakoihin (esimerkiksi tämä voi olla yleinen projektilompakko).
turvallisuus:
- hyökkäyspinta on yleensä pieni;
- Toimintamekanismien perusteella palvelun pitäisi pystyä lähettämään varoja itsenäisesti, joten palvelimelle pääsy tarkoittaa joka tapauksessa varojen hallintaa - ratkaisu voi olla vain ei-automaattisessa tilassa toimiminen (esim. maksut manuaalisesti), mikä on todennäköistä (jos projekti on riittävän onnistunut, jotta joku voi lahjoittaa tähän toimintoon, niin ei ole todennäköistä, mutta ehdottomasti), että se toteutetaan joskus;
- kriittiset osat erotetaan selvästi toisistaan (itse asiassa tämä on yksi 200 rivin pay.go-tiedosto), mikä yksinkertaistaa suojakoodin tarkistusta;
- koodi on läpäissyt riippumattoman suojakooditarkistuksen, mikä ei tarkoita haavoittuvuuksien puuttumista, mutta vähentää niiden esiintymisen todennäköisyyttä, etenkin kun otetaan huomioon suunniteltu tarkistusten säännöllisyys;
- on myös osia, joita ei valvota (esim. API GitHub/GitLab/jne.), kun taas mahdolliset kolmannen osapuolen API:n haavoittuvuudet on tarkoitus sulkea lisätarkastuksilla, mutta yleensä ongelma on nykyisessä ekosysteemi on ratkaisematon ja soveltamisalan ulkopuolella (mahdollisella haavoittuvuudella, joka liittyy esimerkiksi kykyyn sulkea muiden ihmisten vetopyyntöjä ja siten lisätä koodia muiden projekteihin - sillä on paljon globaalimpia seurauksia).
Lähde: linux.org.ru