Представлен donate ― self-hosted сервис пожертвований на задачи


Представлен donate ― self-hosted сервис пожертвований на задачи

Особенности:

  • 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