Features:
- KISS;
- self-hosted;
- no fees (for example, bountysource and gitcoin take 10% from payouts);
- support for multiple cryptocurrencies (currently Bitcoin, Ethereum, and Cardano);
- support for GitLab, Gitea, and other Git hosting services is planned (and provided for) in the future.
- a global task list from all (i.e., one at the time of writing this news) instances on donate.dumpstack.io.
Operation mechanism for GitHub from the repository owner's side:
- (optionally) it is necessary to deploy the service, a prepared configuration for NixOS can be used;
- it is necessary to add GitHub Action — a utility is invoked inside, which scans the project's tasks and adds/updates a comment about the current state of the donation wallets, while the private part of the wallets is stored only on the donation server (in the future, there will be an option to move it offline for large donations, for manual confirmation of payments);
- a message from github-actions[bot] with wallet addresses for donations appears in all current tasks (and new ones);an example).
Operation mechanism from the executor's side:
- the commit comment indicates which specific task this commit addresses (see closing issues using keywords);
- the pull request body specifies wallet addresses in a specific format (e.g., BTC{address}).
- upon acceptance of the pull request, the payment is made automatically.
- if wallets are not specified, or not all are specified, then funds for unspecified wallets are made to the default wallets (for example, this could be the project's general wallet).
Security:
- the attack surface is overall small;
- based on the operational mechanisms, the service must have the ability to send funds independently, so gaining access to the server would mean control over the funds in any case — the only solution might be to operate in a non-automated mode (for example, manual confirmation of payments), which is likely (if the project is successful enough for someone to donate for this functionality, then it is not likely, but certain) to be implemented at some point;
- critical parts are clearly separated (essentially, this is a single file pay.go with 200 lines), thereby simplifying the security code review;
- The code has undergone an independent security code review, which does not guarantee the absence of vulnerabilities, but reduces the likelihood of their presence, especially in light of the planned regular reviews;
- There are also parts that are not controlled (e.g., GitHub/GitLab/etc. APIs). Possible vulnerabilities in third-party APIs will be addressed through additional checks; however, the broader issue in the current ecosystem remains unsolvable and out of scope (for instance, a possible vulnerability allowing the closure of someone else's pull requests and thereby injecting code into their projects has much more significant consequences).
Source: linux.org.ru
