Особливості:
- KISS;
- self-hosted;
- відсутність зборів (для прикладу, шкодаsource і 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