Caratteristiche:
- BACIO;
- ospitato autonomamente;
- nessuna commissione (ad esempio, bountysource e gitcoin prendono il 10% del pagamento);
- supporto per molte criptovalute (attualmente Bitcoin, Ethereum e Cardano);
- è previsto (e fornito) il supporto di GitLab, Gitea e altri servizi di hosting Git in futuro.
- elenco globale di attività da tutte le istanze (cioè una, al momento della stesura della notizia) su donate.dumpstack.io.
Il meccanismo di lavoro per GitHub dal lato del proprietario del repository:
- (facoltativo) è necessario distribuire il servizio, è possibile utilizzarlo configurazione già pronta per NixOS;
- è necessario aggiungere Azione GitHub — all'interno viene richiamata 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 viene archiviata solo sul server delle donazioni (in futuro, con la possibilità di prenderla offline per donazioni di grandi dimensioni, per conferma manuale del pagamento);
- in tutte le attività correnti (e in quelle nuove) appare un messaggio azioni-github[bot] con indirizzi di portafoglio per le donazioni (esempio).
Il meccanismo di lavoro da parte della persona che svolge l'attività:
- il commento al commit indica esattamente quale problema risolve questo commit (vedi. chiudere i problemi utilizzando parole chiave);
- il corpo della richiesta pull specifica gli indirizzi del portafoglio in un formato specifico (ad esempio, BTC{indirizzo}).
- Quando una richiesta pull viene accettata, il pagamento viene effettuato automaticamente.
- se i portafogli non sono specificati, o non sono specificati tutti, il pagamento dei fondi per i portafogli non specificati verrà effettuato sui portafogli predefiniti (ad esempio, potrebbe trattarsi di un portafoglio di progetto generale).
Sicurezza:
- la superficie di attacco è generalmente piccola;
- In base ai meccanismi di funzionamento, il servizio dovrebbe essere in grado di inviare fondi in modo indipendente, quindi ottenere l'accesso al server significherà comunque il controllo sui fondi - la soluzione può essere solo quella di lavorare in modalità non automatizzata (ad esempio, confermando pagamenti manualmente), il che è probabile (se il progetto ha abbastanza successo da consentire a qualcuno di donare per questa funzionalità, allora non è probabile, ma sicuramente) che un giorno verrà implementato;
- le parti critiche sono chiaramente separate (si tratta infatti di un unico file pay.go di 200 righe), semplificando così la revisione del codice di sicurezza;
- il codice ha superato una revisione indipendente del codice di sicurezza, il che non significa assenza di vulnerabilità, ma riduce la probabilità della loro presenza, soprattutto alla luce della prevista regolarità delle revisioni;
- ci sono anche parti non controllate (ad esempio API GitHub/GitLab/ecc.), mentre è prevista la chiusura di eventuali vulnerabilità nelle API di terze parti con controlli aggiuntivi, tuttavia, in generale, il problema allo stato attuale l'ecosistema è irrisolvibile e fuori portata (la possibile vulnerabilità con, ad esempio, la capacità di chiudere le richieste pull di altre persone e quindi aggiungere codice ai progetti di altre persone - ha conseguenze molto più globali).
Fonte: linux.org.ru