Features:
- KUS;
- zelf-gehost;
- geen kosten (bountysource en gitcoin nemen bijvoorbeeld 10% van de betaling);
- ondersteuning voor veel cryptocurrencies (momenteel Bitcoin, Ethereum en Cardano);
- Er wordt verwacht (en aangeboden) dat het in de toekomst GitLab, Gitea en andere Git-hostingdiensten zal ondersteunen.
- globale lijst met taken van alle (dat wil zeggen één, op het moment dat het nieuws werd geschreven) instanties doneer.dumpstack.io.
Het werkmechanisme voor GitHub vanaf de kant van de repository-eigenaar:
- (optioneel) u moet de service implementeren, u kunt deze gebruiken kant-en-klare configuratie voor NixOS;
- moet worden toegevoegd GitHub-actie — er wordt een hulpprogramma binnenin geroepen dat de taken van het project scant en een opmerking toevoegt/bijwerkt over de huidige status van de donatieportefeuilles, terwijl het privégedeelte van de portefeuilles alleen op de donatieserver wordt opgeslagen (in de toekomst, met de mogelijkheid om deze te gebruiken offline voor grote donaties, voor handmatige bevestiging van betaling);
- in alle huidige taken (en nieuwe) verschijnt een bericht github-acties[bot] met portemonnee-adressen voor donaties (voorbeeld).
Het werkmechanisme van de persoon die de taak uitvoert:
- het commentaar bij de commit geeft precies aan welk probleem deze commit oplost (zie. problemen afsluiten met trefwoorden);
- de hoofdtekst van het pull-verzoek specificeert portemonnee-adressen in een specifiek formaat (bijvoorbeeld BTC{adres}).
- Wanneer een pull-request wordt geaccepteerd, wordt de betaling automatisch uitgevoerd.
- als de portefeuilles niet zijn gespecificeerd, of niet allemaal zijn gespecificeerd, wordt de betaling van het geld voor de niet-gespecificeerde portefeuilles gedaan aan de standaardportefeuilles (dit kan bijvoorbeeld een algemene projectportefeuille zijn).
veiligheid:
- het aanvalsoppervlak is doorgaans klein;
- Op basis van de werkingsmechanismen zou de dienst onafhankelijk geld moeten kunnen verzenden, dus het verkrijgen van toegang tot de server betekent in ieder geval controle over het geld - de oplossing kan alleen zijn om in een niet-geautomatiseerde modus te werken (bijvoorbeeld het bevestigen van handmatige betalingen), wat waarschijnlijk is (als het project zo succesvol is dat iemand voor deze functionaliteit wil doneren, dan is het niet waarschijnlijk, maar zeker) dat het ooit zal worden geïmplementeerd;
- kritieke delen zijn duidelijk gescheiden (in feite is dit één pay.go-bestand van 200 regels), waardoor de controle van de beveiligingscode wordt vereenvoudigd;
- de code heeft een onafhankelijke beoordeling van de beveiligingscode doorstaan, wat niet betekent dat er geen kwetsbaarheden zijn, maar wel de kans op hun aanwezigheid verkleint, vooral in het licht van de geplande regelmaat van de beoordelingen;
- er zijn ook onderdelen die niet worden gecontroleerd (bijvoorbeeld API GitHub/GitLab/etc.), terwijl mogelijke kwetsbaarheden in de API van derden naar verwachting zullen worden gedicht met extra controles. Over het algemeen is het probleem echter in de huidige ecosysteem is onoplosbaar en buiten bereik (mogelijke kwetsbaarheid met bijvoorbeeld de mogelijkheid om de pull-verzoeken van anderen te sluiten en daardoor code toe te voegen aan de projecten van anderen - heeft veel meer mondiale gevolgen).
Bron: linux.org.ru