Se presentó donar: un servicio de donación autohospedado para tareas.


Se presentó donar: un servicio de donación autohospedado para tareas.

Características:

  • BESO;
  • autohospedado;
  • sin comisiones (por ejemplo, bountysource y gitcoin cobran el 10% del pago);
  • soporte para muchas criptomonedas (actualmente Bitcoin, Ethereum y Cardano);
  • Se espera (y se proporciona) que admita GitLab, Gitea y otros servicios de alojamiento Git en el futuro.
  • lista global de tareas de todas (es decir, una, en el momento de escribir la noticia) instancias en donar.dumpstack.io.

El mecanismo de trabajo de GitHub por parte del propietario del repositorio:

  • (opcional) necesita implementar el servicio, puede usar configuración lista para usar para NixOS;
  • es necesario agregar Acción de GitHub — dentro se llama una utilidad que escanea las tareas del proyecto y agrega/actualiza un comentario sobre el estado actual de las billeteras de donación, mientras que la parte privada de las billeteras se almacena solo en el servidor de donación (en el futuro, con la capacidad de tomarla fuera de línea para grandes donaciones, para confirmación manual del pago);
  • en todas las tareas actuales (y las nuevas) aparece un mensaje de acciones de github [bot] con direcciones de billetera para donaciones (ejemplo).

El mecanismo de trabajo por parte de la persona que realiza la tarea:

  • el comentario a la confirmación indica exactamente qué problema resuelve esta confirmación (ver. cerrar problemas usando palabras clave);
  • el cuerpo de la solicitud de extracción especifica las direcciones de billetera en un formato específico (por ejemplo, BTC{dirección}).
  • Cuando se acepta una solicitud de extracción, el pago se realiza automáticamente.
  • Si las billeteras no están especificadas, o no están especificadas todas, entonces el pago de los fondos para las billeteras no especificadas se realiza a las billeteras predeterminadas (por ejemplo, esta podría ser una billetera de proyecto general).

Seguridad:

  • la superficie de ataque es generalmente pequeña;
  • Según los mecanismos operativos, el servicio debería poder enviar fondos de forma independiente, por lo que obtener acceso al servidor significará control sobre los fondos en cualquier caso; la solución solo puede ser trabajar en un modo no automatizado (por ejemplo, confirmando pagos manualmente), que es probable (si el proyecto es lo suficientemente exitoso como para que alguien haga una donación para esta funcionalidad, entonces no es probable, pero sí seguro) que se implementará algún día;
  • las partes críticas están claramente separadas (de hecho, se trata de un único archivo pay.go de 200 líneas), lo que simplifica la revisión del código de seguridad;
  • el código ha pasado una revisión independiente del código de seguridad, lo que no significa la ausencia de vulnerabilidades, pero reduce la probabilidad de su presencia, especialmente a la luz de la regularidad planificada de las revisiones;
  • también hay partes que no están controladas (por ejemplo, API GitHub/GitLab/etc.), mientras que las posibles vulnerabilidades en la API de terceros están previstas para cerrarse con comprobaciones adicionales, sin embargo, en general, el problema en la actualidad El ecosistema no tiene solución y está fuera de alcance (una posible vulnerabilidad con, por ejemplo, la capacidad de cerrar las solicitudes de extracción de otras personas y, por lo tanto, agregar código a los proyectos de otras personas, tiene consecuencias mucho más globales).

Fuente: linux.org.ru

Añadir un comentario