Correções de segurança saem sempre na versão mais recente. Não há backport para versões anteriores.

Não abra uma issue pública para relatar uma vulnerabilidade.

Use o canal privado do GitHub: Security → Report a vulnerability. Se preferir, mande um e-mail para dev@bernardorodc.com.

Inclua no relato:

• a versão do mkqr (mkqr -V), o sistema operacional e o shell;
• os passos para reproduzir, de preferência com o comando exato;
• o impacto que você consegue demonstrar.

Você recebe uma confirmação em até 7 dias. Se o problema for confirmado, combinamos uma data de divulgação e o crédito no aviso, se você quiser.

O mkqr é uma ferramenta local de linha de comando. Não abre portas, não faz requisições de rede e não envia telemetria. As áreas onde um problema de segurança faria sentido são:

• Escrita de arquivos. -O grava no caminho indicado e cria diretórios pais. Sem -f, o mkqr se recusa a sobrescrever um arquivo existente.
• Clipboard e --open. Chamam programas do sistema (wl-copy, xclip, osascript, PowerShell, xdg-open, open). São sempre invocados com lista de argumentos, nunca por shell.
• Autocomplete. --install-completion escreve em ~/.bashrc, ~/.zshrc e nos diretórios de completion do shell, sempre dentro de um bloco delimitado que o --uninstall-completion remove.
• --logo. Abre uma imagem que você indicou usando o Pillow. Falhas de parsing de imagem são do Pillow; mantenha-o atualizado.
• Conteúdo do QR. O mkqr codifica o que você mandar, sem validar. Um QR gerado a partir de conteúdo não confiável carrega esse conteúdo para quem o ler.

Ligado neste repositório, e verificável por qualquer pessoa na aba Security:

• Secret scanning e push protection: um commit que contenha uma credencial reconhecida é barrado antes de entrar.

• CodeQL em python e actions, a cada push e pull request. A análise de actions cobre os workflows, não só o código.

• Dependabot: alertas, atualizações de segurança e PRs semanais para as dependências e para as GitHub Actions.

• main protegido: sem force-push, sem deleção, histórico linear e sete checks obrigatórios (testes nos três sistemas, screenshots e CodeQL).

• Publicação no PyPI por Trusted Publishing (OIDC), a partir de um environment que só aceita tags v*. Não existe token nem secret de PyPI guardado no repositório, então não há o que vazar.

• Atestados de proveniência (PEP 740) em cada arquivo publicado. O PyPI guarda a prova de que aquele wheel saiu deste workflow, neste repositório, e qualquer pessoa pode conferir sem depender da nossa palavra:

  curl -s https://pypi.org/integrity/mkqr/0.1.3/mkqr-0.1.3-py3-none-any.whl/provenance \
    | python3 -m json.tool | grep -A3 publisher

• GitHub Actions fixadas por SHA, não por tag. Tag pode ser movida para outro commit; SHA não. Como o workflow de release tem permissão de publicar no PyPI, uma action comprometida publicaria um pacote em nome do projeto — o SHA fecha esse caminho. O Dependabot continua propondo as atualizações.

Está fora de escopo: vulnerabilidades em dependências que já tenham aviso publicado (reporte no projeto de origem), e comportamento que dependa de o atacante já ter execução de código na sua máquina.