Características:
- KISS;
- auto-hospedado;
- ausência de taxas (por exemplo, bountysource e gitcoin retêm 10% do pagamento);
- suporte a várias criptomoedas (atualmente, Bitcoin, Ethereum e Cardano);
- prevê (e está planejado) suporte ao GitLab, Gitea e outros hospedagens Git no futuro.
- lista global de tarefas de todas (ou seja, uma, no momento da escrita da notícia) instâncias em donate.dumpstack.io.
Mecanismo de operação para o GitHub do lado do proprietário do repositório:
- (opcional) é necessário implantar o serviço, pode-se usar uma configuração pronta para NixOS;
- é necessário adicionar GitHub Action — dentro, é chamada uma utilidade que escaneia as tarefas do projeto e adiciona/atualiza um comentário sobre o estado atual das carteiras para doações, enquanto a parte privada das carteiras é armazenada apenas no servidor de doações (no futuro com a possibilidade de ser movida offline para grandes doações, para confirmação manual de pagamento);
- todas as tarefas atuais (e novas) apresentam uma mensagem de github-actions[bot] com os endereços das carteiras para doações (exemplo).
Mecanismo de operação do lado da pessoa que realiza a tarefa:
- no comentário do commit, é indicado qual tarefa específica este commit resolve (veja. fechamento de problemas usando palavras-chave);
- no corpo do pull request, os endereços das carteiras são indicados em um formato específico (por exemplo, BTC{endereço}).
- ao aceitar o pull request, o pagamento é realizado automaticamente.
- se os endereços das carteiras não forem indicados ou não forem todos indicados, o pagamento para os endereços não especificados será feito nas carteiras padrão (por exemplo, pode ser uma carteira comum do projeto).
Segurança:
- a superfície de ataque é, em geral, pequena;
- com base nos mecanismos de operação, o serviço deve ter a capacidade de enviar fundos por conta própria, então obter acesso ao servidor significará controle sobre os fundos em qualquer caso — a única solução pode ser trabalhar em modo não automatizado (por exemplo, confirmação manual de pagamentos), que provavelmente (se o projeto for bem-sucedido o suficiente para que alguém contribua para essa funcionalidade, então não é improvável, mas certo) será implementada algum dia;
- partes críticas estão claramente separadas (na verdade, é um único arquivo pay.go de 200 linhas), simplificando assim a revisão de segurança do código;
- o código passou por uma revisão de segurança independente, o que não significa que não haja vulnerabilidades, mas reduz a probabilidade de sua existência, especialmente à luz da regularidade planejada das revisões;
- também existem partes que não são controladas (por exemplo, API GitHub/GitLab/etc.), e as vulnerabilidades potenciais na API de terceiros estão planejadas para serem tratadas com verificações adicionais, no entanto, em geral, o problema na atual ecossistema é insolúvel e fora do escopo (a vulnerabilidade potencial com, por exemplo, a capacidade de fechar pull requests de outros e, assim, adicionar código a projetos alheios — tem consequências muito mais globais).
Fonte: linux.org.ru
