Caratteristiche:
- KISS;
- self-hosted;
- assenza di commissioni (ad esempio, bountysource e gitcoin prendono il 10% del pagamento);
- supporto per molte criptovalute (attualmente Bitcoin, Ethereum e Cardano);
- si prevede (e si intende) supportare GitLab, Gitea e altri hosting Git in futuro.
- lista globale delle attività da tutti (cioè uno, al momento della scrittura della notizia) gli istanziamenti su donate.dumpstack.io.
Meccanismo di funzionamento per GitHub dal punto di vista del proprietario del repository:
- (opzionale) è necessario distribuire il servizio, si può usare una configurazione pronta per NixOS;
- è necessario aggiungere GitHub Action — all'interno viene chiamato uno strumento 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 passare 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 (esempio).
Meccanismo di funzionamento dal punto di vista dell'esecutore dell'attività:
- nel commento del commit viene indicato quale attività specifica risolve questo commit (vedi. chiudere le questioni usando parole chiave);
- nel corpo della pull request vengono indicati gli indirizzi dei portafogli in un formato specifico (ad esempio, BTC{address}).
- all'accettazione della pull request 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 sui portafogli predefiniti (ad esempio, questo può essere un portafoglio comune del progetto).
Sicurezza:
- la superficie di attacco è complessivamente ridotta;
- in base ai meccanismi di funzionamento, il servizio deve avere la possibilità di inviare fondi autonomamente, quindi ottenere accesso al server significherebbe controllare fondi in qualsiasi caso — la soluzione può essere solo lavorare in modalità non automatizzata (ad esempio, confermare i pagamenti manualmente), che probabilmente (se il progetto sarà sufficientemente di successo affinché qualcuno doni a questa funzionalità, quindi non probabilmente, ma sicuramente) sarà implementata in futuro;
- le parti critiche sono chiaramente separate (di fatto, si tratta di un unico file pay.go di 200 righe), semplificando così la revisione della sicurezza del codice;
- il codice ha superato una revisione del codice di sicurezza indipendente, il che non significa assenza di vulnerabilità, ma riduce la probabilità della loro presenza, soprattutto alla luce della regolarità programmata delle revisioni;
- ci sono anche parti che non sono controllabili (ad esempio, API GitHub/GitLab/etc.), tuttavia le vulnerabilità potenziali in API di terze parti si prevede di chiudere con controlli aggiuntivi, tuttavia, nel complesso, il problema nell'attuale ecosistema è irrisolvibile e out of scope (una vulnerabilità potenziale con, ad esempio, la possibilità di chiudere le pull request altrui e quindi aggiungere codice a progetti altrui — ha conseguenze molto più globali).
Fonte: linux.org.ru
