Características:
- KISS;
- autoalojado;
- ausencia de comisiones (por ejemplo, bountysource y gitcoin se quedan con el 10% del pago);
- soporte para múltiples criptomonedas (actualmente Bitcoin, Ethereum y Cardano);
- se prevé (y está previsto) soporte para GitLab, Gitea y otros alojamientos de Git en el futuro.
- lista global de tareas de todas (es decir, de una en el momento de la escritura de la noticia) las instancias en donate.dumpstack.io.
Mecanismo de funcionamiento para GitHub desde la perspectiva del propietario del repositorio:
- (opcional) es necesario desplegar el servicio, se puede utilizar una configuración lista para NixOS;
- es necesario añadir GitHub Action — dentro se invoca una utilidad que escanea las tareas del proyecto y añade/actualiza un comentario sobre el estado actual de las wallets para donaciones, mientras que la parte privada de las wallets se almacena solo en el servidor de donaciones (en el futuro con la posibilidad de llevarla a offline para donaciones grandes, para la confirmación manual de pagos);
- en todas las tareas actuales (y nuevas) aparece un mensaje de github-actions[bot] con las direcciones de las wallets para donaciones (ejemplo).
Mecanismo de funcionamiento desde la perspectiva del ejecutor de la tarea:
- en el comentario del commit se indica qué tarea específica resuelve este commit (ver. cerrar problemas usando palabras clave);
- en el cuerpo de la solicitud de extracción se indican las direcciones de las wallets en un formato específico (por ejemplo, BTC{address}).
- al aceptar la solicitud de extracción, el pago se realiza automáticamente.
- si las wallets no están indicadas, o no todas están indicadas, el pago de fondos para las wallets no indicadas se realiza a las wallets por defecto (por ejemplo, podría ser la wallet general del proyecto).
Seguridad:
- la superficie de ataque en general es pequeña;
- basado en los mecanismos de funcionamiento, el servicio debe tener la capacidad de enviar fondos por sí mismo, por lo que el acceso al servidor significará control sobre los fondos en cualquier caso; la única solución puede ser trabajar en un modo no automatizado (por ejemplo, confirmar pagos manualmente), lo cual probablemente (si el proyecto tiene éxito suficiente como para que alguien done para esta funcionalidad, entonces no es probable, sino seguro) se implementará en algún momento;
- las partes críticas están claramente separadas (de hecho, este es el único archivo pay.go de 200 líneas), simplificando así la revisión de seguridad del código;
- El código ha pasado una revisión de seguridad independiente, lo que no implica la ausencia de vulnerabilidades, pero reduce la probabilidad de su existencia, especialmente considerando la regularidad de las revisiones programadas;
- También hay partes que no están bajo control (por ejemplo, API de GitHub/GitLab/etc.), por lo que las posibles vulnerabilidades en API externas se abordarán con comprobaciones adicionales. Sin embargo, en general, el problema en el ecosistema actual es irresoluble y está fuera de alcance (posible vulnerabilidad, por ejemplo, que permite cerrar pull requests ajenos y así añadir código a proyectos de terceros, con consecuencias mucho más globales).
Fuente: linux.org.ru
