Voici donate ― un service de dons auto-hébergé pour des projets

Caractéristiques :

• KISS;
• auto-hébergé;
• absence de frais (par exemple, bountysource et gitcoin prennent 10% sur les paiements);
• prise en charge de plusieurs crypto-monnaies (actuellement Bitcoin, Ethereum et Cardano);
• un support pour GitLab, Gitea et d'autres hébergeurs Git est prévu à l'avenir.
• liste des tâches globale provenant de tous (c'est-à-dire un, au moment de la rédaction de l'article) les instances sur donate.dumpstack.io.

Mécanisme de fonctionnement pour GitHub côté propriétaire du dépôt :

• (optionnel) il est nécessaire de déployer le service, une configuration prête pour NixOS peut être utilisée;
• il est nécessaire d'ajouter GitHub Action — à l'intérieur, un utilitaire est appelé, qui scanne les tâches du projet et ajoute/actualise un commentaire sur l'état actuel des portefeuilles pour les dons, la partie privée des portefeuilles étant stockée uniquement sur le serveur de dons (dans le futur, avec la possibilité d'être déplacée hors ligne pour de plus gros dons, pour la confirmation manuelle du paiement);
• dans toutes les tâches actuelles (et nouvelles), un message de github-actions[bot] avec les adresses de portefeuille pour les dons apparaît (exemple).

Mécanisme de fonctionnement côté exécuteur de la tâche :

• dans le commentaire du commit, il est indiqué quelle tâche ce commit résout (voir fermeture des problèmes à l'aide de mots-clés);
• dans le corps de la demande de tirage, les adresses des portefeuilles sont indiquées dans un format spécifique (par exemple, BTC{adresse}).
• lorsque la demande de tirage est acceptée, le paiement est effectué automatiquement.
• si les portefeuilles ne sont pas indiqués, ou si tous ne sont pas indiqués, alors le paiement pour les portefeuilles non indiqués est effectué sur les portefeuilles par défaut (par exemple, cela peut être un portefeuille de projet commun).

Sécurité :

• la surface d'attaque est globalement petite;
• en raison des mécanismes de fonctionnement, le service doit avoir la capacité d'envoyer des fonds lui-même, donc obtenir l'accès au serveur signifiera le contrôle des fonds dans tous les cas — la seule solution peut être de travailler en mode non automatisé (par exemple, confirmation des paiements manuellement), qui sera probablement (si le projet devient suffisamment réussi pour qu'un don soit fait pour cette fonctionnalité, alors non seulement probable, mais certain) un jour mise en œuvre;
• les parties critiques sont clairement séparées (il s'agit en fait d'un seul fichier pay.go de 200 lignes), simplifiant ainsi la révision de code de sécurité;
• Le code a passé une révision de sécurité indépendante, ce qui n'indique pas l'absence de vulnérabilités, mais réduit la probabilité de leur existence, surtout compte tenu de la fréquence de révisions prévue ;
• Il existe également des parties qui ne sont pas contrôlées (par exemple, les API GitHub/GitLab/etc.), les vulnérabilités potentielles dans des API tierces seront comblées par des vérifications supplémentaires, néanmoins, dans l'ensemble, le problème dans l'écosystème actuel est insoluble et hors de portée (une vulnérabilité potentielle, par exemple, permettant de fermer des pull requests d'autres utilisateurs et ainsi d'ajouter du code à des projets étrangers — a des conséquences beaucoup plus globales).

Source : linux.org.ru