Асаблівасці:
- KISS;
- self-hosted;
- адсутнасць збораў (для прыкладу, bountysource і gitcoin забіраюць сабе 10% ад выплаты);
- падтрымка мноства криптовалют (цяпер гэта Bitcoin, Ethereum і Cardano);
- мяркуецца (і прадугледжана) падтрымка GitLab, Gitea, і іншых Git-хостынгаў у будучыні.
- глабальны спіс задач з усіх (гэта значыць аднаго, на момант напісання навіны) інстансаў на donate.dumpstack.io.
Механізм працы для GitHub з боку ўладальніка рэпазітара:
- (апцыянальна) неабходна разгарнуць сэрвіс, можна выкарыстоўваць гатовую канфігурацыю для NixOS;
- неабходна дадаць GitHub Action - Унутры выклікаецца ўтыліта, якая скануе задачы праекта і дадае / абнаўляе каментар аб бягучым стане кашалькоў для ахвяраванняў, пры гэтым прыватная частка кашалькоў захоўваецца толькі на серверы ахвяраванняў (у будучыні з магчымасцю вынесці ў афлайн для буйных ахвяраванняў, для ручнога пацверджання выплаты);
- ва ўсіх бягучых задачах (і новых) з'яўляецца паведамленне ад github-actions[bot] з адрасамі кашалькоў для ахвяраванняў (прыклад).
Механізм працы з боку выконваючага задачу:
- у каментары да коміта ўказваецца, якую менавіта задачу гэты коміт вырашае (гл. closing issues using keywords);
- у целе pull request паказваюцца адрасы кашалькоў у вызначаным фармаце (напрыклад, BTC{address}).
- пры прыняцці pull request выплата здзяйсняецца аўтаматычна.
- калі кашалькі не пазначаны, альбо пазначаны не ўсе, то выплата сродкаў для неўказаных кашалькоў здзяйсняецца на кашалькі па-змаўчанні (напрыклад, гэта можа быць агульны кашалёк праекта).
бяспека:
- паверхня нападу ў цэлым невялікая;
- зыходзячы з механізмаў працы, сэрвіс павінен мець магчымасць адпраўляць сродкі самастойна, так што атрыманне доступу да сервера будзе азначаць кантроль над сродкамі ў любым выпадку - рашэннем можа быць толькі праца ў неаўтаматызаваным рэжыме (напрыклад, пацверджанне выплат уручную), якая верагодна (калі праект будзе дастаткова паспяховы для таго, каб нехта заданаціў на гэтую функцыянальнасць, то не верагодна, а дакладна) будзе калісьці рэалізаваная;
- крытычна важныя часткі выразна аддзеленыя (па сутнасці, гэта адзіны файл pay.go на 200 радкоў), тым самым спрашчаючы security code review;
- код прайшоў незалежнае security code review, што не азначае адсутнасць уразлівасцяў, але змяншае верагоднасць іх наяўнасці, асабліва ў святле запланаванай рэгулярнасці рэўю;
- таксама ёсць тыя часткі, якія не кантралююцца (напрыклад, API GitHub/GitLab/etc.), пры гэтым магчымыя ўразлівасці ў іншым API плануецца зачыняць дадатковымі праверкамі, тым не менш, у цэлым праблема ў бягучай экасістэме невырашальная і out of scope (магчымая ўразлівасць з, напрыклад, магчымасцю зачыняць чужыя pull request і тым самым дадаваць код у чужыя праекты ― мае значна больш глабальныя наступствы).
Крыніца: linux.org.ru