Особенности: KISS; self-hosted; отсутствие сборов (для примера, bountysource и gitcoin забирают себе 10% от выплаты); поддержка множества криптовалют (на данный момент это Bitcoin, Ethereum и Cardano); предполагается (и предусмотрена) поддержка GitLab, Gitea, и других Git-хостингов в будущем. глобальный список задач со всех (то есть одного, на момент написания новости) инстансов на [ donate.dumpstack.io ](
https://donate.dumpstack.io ) . Механизм работы для GitHub со стороны владельца репозитория: (опционально) необходимо развернуть сервис, можно использовать [ готовую конфигурацию для NixOS ](
https://github.com/jollheef/donate/tree/master/deploy ) ; необходимо добавить [ GitHub Action ](
https://github.com/jollheef/donate/blob/master/.github/workflows/donate.yml ) — внутри вызывается утилита, которая сканирует задачи проекта и добавляет/обновляет комментарий о текущем состоянии кошельков для пожертвований, при этом приватная часть кошельков хранится только на сервере пожертвований (в будущем с возможностью вынести в оффлайн для крупных пожертвований, для ручного подтверждения выплаты); во всех текущих задачах (и новых) появляется сообщение от github-actions[bot] с адресами кошельков для пожертвований ( [ пример ](
https://github.com/jollheef/donate/issues/4#issuecomment-575398821 ) ). Механизм работы со стороны выполняющего задачу: в комментарии к коммиту указывается, какую именно задачу этот коммит решает (см. [ closing issues using keywords ](
https://help.github.com/en/github/managing-your-work-on-github/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 и тем самым добавлять код в чужие проекты ― имеет гораздо более глобальные последствия).
Ссылка:
https://www.linux.org.ru/news/opensource/15479616