Características:
- BICO;
- autoaloxado;
- sen taxas (por exemplo, bountysource e gitcoin levan o 10% do pago);
- soporte para moitas criptomoedas (actualmente Bitcoin, Ethereum e Cardano);
- No futuro espérase (e ofrécese) soporte para GitLab, Gitea e outros servizos de hospedaxe de Git.
- lista global de tarefas de todas as instancias (é dicir, unha, no momento de escribir a noticia). donate.dumpstack.io.
O mecanismo de traballo para GitHub dende o lado do propietario do repositorio:
- (opcional) precisa implementar o servizo, pode usar configuración preparada para NixOS;
- hai que engadir Acción GitHub — chámase unha utilidade no interior que analiza as tarefas do proxecto e engade/actualiza un comentario sobre o estado actual das carteiras de doazóns, mentres que a parte privada das carteiras só se almacena no servidor de doazóns (no futuro, coa posibilidade de levala). fóra de liña para grandes doazóns, para a confirmación manual do pago);
- en todas as tarefas actuais (e nas novas) aparece unha mensaxe desde accións-github[bot] con enderezos de carteira para doazóns (exemplo).
O mecanismo de traballo por parte da persoa que realiza a tarefa:
- o comentario ao commit indica exactamente que problema resolve este commit (ver. problemas de peche mediante palabras clave);
- o corpo da solicitude de extracción especifica enderezos de carteira nun formato específico (por exemplo, BTC{enderezo}).
- Cando se acepta unha solicitude de extracción, o pago realízase automaticamente.
- se non se especifican as carteiras ou non se especifican todas, entón o pago dos fondos para as carteiras non especificadas realízase ás carteiras predeterminadas (por exemplo, esta podería ser unha carteira de proxecto xeral).
Seguridade:
- a superficie de ataque é xeralmente pequena;
- En función dos mecanismos operativos, o servizo debería poder enviar fondos de forma independente, polo que acceder ao servidor significará controlar os fondos en calquera caso; a solución só pode ser traballar nun modo non automatizado (por exemplo, confirmando pagos manualmente), o que é probable (se o proxecto é o suficientemente exitoso como para que alguén poida doar para esta función, entón non é probable, pero definitivamente) que se implemente algún día;
- as partes críticas están claramente separadas (de feito, este é un único ficheiro pay.go de 200 liñas), simplificando así a revisión do código de seguridade;
- o código aprobou unha revisión independente do código de seguridade, o que non significa a ausencia de vulnerabilidades, senón que reduce a probabilidade da súa presenza, especialmente á luz da regularidade prevista das revisións;
- tamén hai aquelas partes que non están controladas (por exemplo, API GitHub/GitLab/etc.), mentres que as posibles vulnerabilidades da API de terceiros están previstas para pecharse con comprobacións adicionais, non obstante, en xeral, o problema no actual O ecosistema é irresoluble e está fóra de alcance (a posible vulnerabilidade con, por exemplo, a capacidade de pechar as solicitudes de extracción doutras persoas e, polo tanto, engadir código aos proxectos doutras persoas, ten consecuencias moito máis globais).
Fonte: linux.org.ru