Característiques:
- PETON;
- autoallotjat;
- sense comissions (per exemple, bountysource i gitcoin cobren el 10% del pagament);
- suport per a moltes criptomonedes (actualment Bitcoin, Ethereum i Cardano);
- s'espera (i proporciona) que sigui compatible amb GitLab, Gitea i altres serveis d'allotjament de Git en el futur.
- llista global de tasques de totes les instàncies (és a dir, una, en el moment d'escriure la notícia). donate.dumpstack.io.
El mecanisme de treball per a GitHub des del propietari del dipòsit:
- (opcional) necessiteu desplegar el servei, podeu utilitzar configuració preparada per a NixOS;
- cal afegir Acció GitHub — Es diu una utilitat a l'interior que escaneja les tasques del projecte i afegeix/actualitza un comentari sobre l'estat actual de les carteres de donació, mentre que la part privada de les carteres només s'emmagatzema al servidor de donacions (en el futur, amb la possibilitat d'agafar-la). fora de línia per a grans donacions, per a la confirmació manual del pagament);
- en totes les tasques actuals (i les noves) apareix un missatge github-actions[bot] amb adreces de cartera per a donacions (exemple).
El mecanisme de treball per part de la persona que realitza la tasca:
- el comentari al commit indica exactament quin problema resol aquest commit (vegeu. tancament de problemes amb paraules clau);
- el cos de la sol·licitud d'extracció especifica adreces de cartera en un format específic (per exemple, BTC{adreça}).
- Quan s'accepta una sol·licitud d'extracció, el pagament es realitza automàticament.
- si no s'especifiquen les carteres o no s'especifiquen totes, el pagament dels fons per a les carteres no especificades es fa a les carteres predeterminades (per exemple, aquesta podria ser una cartera de projecte general).
Seguretat:
- la superfície d'atac és generalment petita;
- Segons els mecanismes operatius, el servei hauria de poder enviar fons de manera independent, de manera que accedir al servidor significarà controlar els fons en qualsevol cas; la solució només pot ser treballar en un mode no automatitzat (per exemple, confirmant pagaments manualment), la qual cosa és probable (si el projecte té prou èxit perquè algú faci una donació per a aquesta funcionalitat, no és probable, però definitivament) que s'implementarà algun dia;
- les parts crítiques estan clarament separades (de fet, es tracta d'un únic fitxer pay.go de 200 línies), simplificant així la revisió del codi de seguretat;
- el codi ha passat una revisió independent del codi de seguretat, la qual cosa no significa l'absència de vulnerabilitats, sinó que redueix la probabilitat de la seva presència, sobretot a la vista de la regularitat planificada de les revisions;
- també hi ha aquelles parts que no estan controlades (per exemple, API GitHub/GitLab/etc.), mentre que es preveu que les possibles vulnerabilitats de l'API de tercers es tanquin amb comprovacions addicionals, però, en general, el problema en l'actual L'ecosistema és irresoluble i està fora de l'abast (la possible vulnerabilitat amb, per exemple, la capacitat de tancar les sol·licituds d'extracció d'altres persones i, per tant, afegir codi als projectes d'altres persones, té conseqüències molt més globals).
Font: linux.org.ru