Удобства:
- ЦЕЛУВКА;
- самостоятелно хостван;
- без такси (например bountysource и gitcoin вземат 10% от плащането);
- поддръжка на много криптовалути (в момента Bitcoin, Ethereum и Cardano);
- поддръжка за GitLab, Gitea и други Git хостинг услуги се очаква (и се предоставя) в бъдеще.
- глобален списък със задачи от всички (т.е. един, към момента на писане на новината) инстанции на donate.dumpstack.io.
Механизмът на работа за GitHub от страна на собственика на хранилището:
- (по избор) трябва да разположите услугата, можете да използвате готова конфигурация за NixOS;
- трябва да се добави GitHub действие — вътре се извиква помощна програма, която сканира задачите на проекта и добавя/актуализира коментар за текущото състояние на портфейлите за дарения, докато личната част от портфейлите се съхранява само на сървъра за дарения (в бъдеще, с възможността да го вземете офлайн за големи дарения, за ръчно потвърждение на плащане);
- във всички текущи задачи (и нови) се появява съобщение от github-действия[бот] с адреси на портфейли за дарения (пример).
Механизмът на работа от страна на лицето, изпълняващо задачата:
- коментарът към ангажимента показва точно какъв проблем решава този комит (вижте. затваряне на въпроси с помощта на ключови думи);
- тялото на заявката за изтегляне указва адресите на портфейла в специфичен формат (например, BTC{адрес}).
- Когато заявка за изтегляне бъде приета, плащането се извършва автоматично.
- ако портфейлите не са посочени или не всички са посочени, тогава плащането на средства за неспецифицираните портфейли се извършва към портфейлите по подразбиране (например, това може да е портфейл за общ проект).
сигурност:
- атакуващата повърхност обикновено е малка;
- Въз основа на механизмите на работа услугата трябва да може да изпраща средства независимо, така че получаването на достъп до сървъра ще означава контрол върху средствата във всеки случай - решението може да бъде само работа в неавтоматизиран режим (например потвърждение плащания ръчно), което е вероятно (ако проектът е достатъчно успешен, за да може някой да дари за тази функционалност, тогава е малко вероятно, но определено), че ще бъде реализиран някой ден;
- критичните части са ясно разделени (всъщност това е един файл pay.go от 200 реда), като по този начин се опростява прегледът на кода за сигурност;
- кодът е преминал независим преглед на кода за сигурност, което не означава липса на уязвимости, но намалява вероятността от тяхното присъствие, особено в светлината на планираната редовност на прегледите;
- има и такива части, които не се контролират (например API GitHub/GitLab/и т.н.), докато възможните уязвимости в API на трета страна се планират да бъдат затворени с допълнителни проверки, но като цяло проблемът в текущия екосистемата е неразрешима и извън обхвата (възможна уязвимост с, например, способността да затваряте заявки за изтегляне на други хора и по този начин да добавяте код към проекти на други хора - има много по-глобални последици).
Източник: linux.org.ru