Features:
- KUS;
- zelf gehost;
- geen kosten (bijvoorbeeld bountysource en gitcoin nemen 10% van de betaling);
- ondersteuning voor meerdere cryptovaluta (momenteel Bitcoin, Ethereum en Cardano);
- Ondersteuning voor GitLab, Gitea en andere Git-hostingdiensten wordt in de toekomst verwacht (en geleverd).
- wereldwijde lijst van taken van alle (dat wil zeggen één, op het moment dat het nieuws werd geschreven) instanties op doneer.dumpstack.io.
Het werkmechanisme voor GitHub vanuit het perspectief van de eigenaar van de repository:
- (optioneel) u moet de service implementeren, u kunt hiervoor gebruiken kant-en-klare configuratie voor NixOS;
- moet toevoegen GitHub-actie — er wordt een hulpprogramma aangeroepen dat de projecttaken scant en een opmerking toevoegt/bijwerkt over de huidige status van de wallets voor donaties, terwijl het privégedeelte van de wallets alleen op de donatieserver wordt opgeslagen (in de toekomst met de mogelijkheid om het offline te verplaatsen voor grote donaties, voor handmatige bevestiging van betalingen);
- in alle huidige taken (en nieuwe) verschijnt een bericht van github-acties[bot] met portemonnee-adressen voor donaties (voorbeeld).
Het werkmechanisme van de kant van de persoon die de taak uitvoert:
- In de commit-opmerking wordt aangegeven welk specifiek probleem de commit oplost (zie problemen sluiten met behulp van trefwoorden);
- In de body van de pull-aanvraag worden wallet-adressen in een specifiek formaat gespecificeerd (bijvoorbeeld BTC{adres}).
- Wanneer een pull request geaccepteerd wordt, wordt de betaling automatisch uitgevoerd.
- Als er geen wallets zijn gespecificeerd, of als niet alle wallets zijn gespecificeerd, dan worden de betalingen voor niet-gespecificeerde wallets gedaan aan de standaardwallets (dit kan bijvoorbeeld de algemene wallet van het project zijn).
veiligheid:
- het aanvalsoppervlak is over het algemeen klein;
- op basis van de werkingsmechanismen zou de dienst zelfstandig geld moeten kunnen versturen, dus toegang tot de server betekent in ieder geval controle over het geld - de enige oplossing kan zijn om in een niet-geautomatiseerde modus te werken (bijvoorbeeld handmatig betalingen bevestigen), wat waarschijnlijk (als het project succesvol genoeg is om iemand aan deze functionaliteit te laten doneren, dan waarschijnlijk niet, maar zeker) op een gegeven moment zal worden geïmplementeerd;
- kritieke onderdelen zijn duidelijk gescheiden (in essentie is het een enkel pay.go-bestand van 200 regels), waardoor de beoordeling van de beveiligingscode wordt vereenvoudigd;
- de code is onderworpen aan een onafhankelijke beoordeling van de beveiligingscode, wat niet betekent dat er geen kwetsbaarheden zijn, maar het vermindert de waarschijnlijkheid dat deze aanwezig zijn, vooral in het licht van de geplande regelmaat van de beoordeling;
- Er zijn ook onderdelen die niet worden beheerd (bijvoorbeeld de API van GitHub/GitLab/enz.). Mogelijke kwetsbaarheden in API's van derden zullen naar verwachting worden gedicht met extra controles. Over het algemeen is het probleem in het huidige ecosysteem echter onoplosbaar en valt het buiten het bereik (een mogelijke kwetsbaarheid met bijvoorbeeld de mogelijkheid om de pull-request van iemand anders te sluiten en daardoor code toe te voegen aan de projecten van iemand anders ― heeft veel meer wereldwijde gevolgen).
Bron: linux.org.ru
