Caratteristiche:
- BACIA;
- autonomo;
- assenza di commissioni (ad esempio, bountysource e gitcoin trattengono il 10% del pagamento);
- supporto per molte criptovalute (attualmente Bitcoin, Ethereum e Cardano);
- è previsto (ed è in programma) il supporto per GitLab, Gitea e altri Git hosting in futuro.
- lista globale delle attività da tutti (cioè uno, al momento della scrittura della notizia) gli istanze su donate.dumpstack.io.
Meccanismo di funzionamento per GitHub dal lato del proprietario del repository:
- (opzionale) è necessario distribuire il servizio, si può utilizzare una configurazione pronta per NixOS;
- è necessario aggiungere GitHub Action — all'interno viene chiamata un'utilità che scansiona le attività del progetto e aggiunge/aggiorna un commento sullo stato attuale dei portafogli per le donazioni, mentre la parte privata dei portafogli è conservata solo sul server delle donazioni (in futuro con la possibilità di essere portata offline per grandi donazioni, per confermare manualmente il pagamento);
- in tutte le attività attuali (e nuove) appare un messaggio da github-actions[bot] con gli indirizzi dei portafogli per le donazioni (un esempio).
Meccanismo di funzionamento dal lato di chi esegue l'attività:
- nel commento al commit si indica quale attività specifica risolve questo commit (vedi. chiudere problemi utilizzando parole chiave);
- nel corpo della pull request vengono indicati gli indirizzi dei portafogli in un formato specifico (ad esempio, BTC{address}).
- quando la pull request viene accettata, il pagamento viene effettuato automaticamente.
- se i portafogli non sono indicati, oppure non sono tutti indicati, il pagamento per i portafogli non specificati viene effettuato verso i portafogli predefiniti (ad esempio, può essere un portafoglio comune del progetto).
Sicurezza:
- la superficie di attacco è complessivamente piccola;
- in base ai meccanismi di funzionamento, il servizio dovrebbe avere la possibilità di inviare fondi autonomamente, quindi l'accesso al server significerebbe controllo sui fondi in ogni caso — la soluzione può essere solo lavorare in modalità non automatizzata (ad esempio, confermare i pagamenti manualmente), che probabilmente (se il progetto sarà abbastanza di successo da far sì che qualcuno doni per questa funzionalità, quindi non è probabile, ma certo) verrà implementata in futuro;
- le parti critiche sono chiaramente separate (in sostanza, si tratta dell'unico file pay.go di 200 righe), semplificando così la revisione della sicurezza del codice;
- Il codice ha superato una revisione di sicurezza indipendente, il che non significa assenza di vulnerabilità, ma riduce la probabilità della loro presenza, soprattutto in vista della regolarità programmata delle revisioni;
- Ci sono anche parti che non sono sotto controllo (ad esempio, API GitHub/GitLab/ect.), e le potenziali vulnerabilità in API esterne si prevede di risolverle con controlli aggiuntivi. Tuttavia, nel complesso il problema nell'attuale ecosistema è irrisolvibile e fuori portata (una possibile vulnerabilità, ad esempio la possibilità di chiudere pull request altrui e quindi aggiungere codice a progetti di terzi, ha conseguenze molto più ampie).
Fonte: linux.org.ru
