Kenmerken:
- KISS;
- zelf-gehosteerd;
- geen kosten (bijvoorbeeld, bountysource en gitcoin houden 10% van de uitbetaling);
- ondersteuning voor meerdere cryptocurrencies (momenteel Bitcoin, Ethereum en Cardano);
- ondersteuning voor GitLab, Gitea, en andere Git-hostings is gepland voor de toekomst.
- een wereldwijde takenlijst van alle (inclusief Ć©Ć©n, op het moment van schrijven) instanties op donate.dumpstack.io.
De werking voor GitHub vanuit het perspectief van de repository-eigenaar:
- (optioneel) het opzetten van de service, een kant-en-klare configuratie voor NixOS kan worden gebruikt.;
- het is nodig om GitHub Action te voegen ā binnenin wordt een tool aangeroepen die de taken van het project scant en een commentaar toevoegt/werkt bij over de huidige status van de donatiewallets, waarbij de privĆ©-informatie van de wallets alleen op de donatieserver wordt bewaard (in de toekomst mogelijk om naar offline te verplaatsen voor grote donaties, voor handmatige bevestiging van uitbetaling);
- in alle huidige taken (en nieuwe) verschijnt er een bericht van github-actions[bot] met de adressen van de donatiewallets (bijvoorbeeld).
De werking vanuit het perspectief van degene die de taak uitvoert:
- in de commentaar van de commit wordt aangegeven welke specifieke taak deze commit oplost (zie closing issues using keywords);
- in de body van de pull request worden de wallet-adressen in een bepaald formaat vermeld (bijvoorbeeld, BTC{address},).
- bij acceptatie van de pull request wordt de uitbetaling automatisch uitgevoerd.
- als de wallets niet zijn aangegeven, of niet allemaal zijn aangegeven, dan wordt de uitbetaling voor niet-gespecificeerde wallets gedaan naar de standaard wallets (bijvoorbeeld, dit kan een gezamenlijke wallet van het project zijn).
Beveiliging:
- de aanvalsvector is over het algemeen klein;
- gezien de werking moet de service in staat zijn om zelf geld te verzenden, dus toegang tot de server krijgen betekent controle over de middelen in elk geval ā de enige oplossing kan zijn om handmatig te werken (bijvoorbeeld, handmatige bevestiging van uitbetalingen), wat waarschijnlijk (als het project succesvol genoeg is dat iemand op deze functionaliteit doneert, dan is het niet waarschijnlijk, maar zeker) ooit zal worden gerealiseerd;
- kritiek belangrijke delen zijn duidelijk gescheiden (dit is in feite het enige bestand pay.go met 200 regels), waardoor security code review eenvoudiger wordt.
- de code heeft een onafhankelijk security code review doorstaan, wat niet betekent dat er geen kwetsbaarheden zijn, maar de kans op aanwezigheid ervan verlaagt, vooral in het licht van de geplande regelmaat van de reviews;
- er zijn ook delen die niet in controle zijn (bijvoorbeeld API's van GitHub/GitLab/etc.), waarbij mogelijke kwetsbaarheden in externe API's zullen worden aangepakt met extra controles, desondanks blijft het probleem in het huidige ecosysteem onoplosbaar en buiten scope (een mogelijke kwetsbaarheid, zoals de mogelijkheid om andermans pull requests te sluiten en zo code toe te voegen aan andermans projecten - heeft veel grotere gevolgen).
Bron: linux.org.ru
