Aqui você pega o código sob as licenças BSD, MIT e Apache2 e não sopra o batedor, e então - bam! - o segundo turno, e na dependência transitiva o código sob AGPL é desenhado. Tentamos ficar de olho nisso e preferimos ultrapassar, em vez de terminar mal.
Antes de adicionar novas dependências a qualquer um dos meus projetos, sempre faço uma verificação básica. O que eu verifico (lista de verificação padrão):
- Sob qual licença o código é emitido?
- Quem é o autor?
- Existem problemas sérios e não resolvidos no rastreador de erros?
- Existe um histórico de erros graves no rastreador de erros?
- Como ocorre uma revisão de código para pull-quests?
Depois disso, vasculho o próprio código em busca de algo obviamente inseguro ou malicioso. Isso é necessário para sentir a qualidade da própria base de código. Em seguida, tento encontrar o
"M & Ms marrom" - pequenos detalhes que podem indicar grandes problemas. E repita repetidamente todas as opções acima com dependências transitivas. Além disso, repito o código toda vez que atualizo a dependência.
É uma quantidade bastante grande de trabalho, mas é necessário para não se tornar vítima de ataques como o
fluxo de eventos . Recentemente, lembrei-me de outro bom motivo para verificar dependências. Naquele momento, eu estava revisando a
biblioteca ativamente anunciada do Duo para WebAuthn on Go, que fica aqui:
github.com/duo-labs/webauthn .
Tudo começou com o fato de eu ter notado alguns "M & M's marrons":
- Os dados foram registrados no stdout, apesar de ser uma biblioteca.
- O código foi armazenado em estoque.
Obviamente, esses pequenos problemas foram apenas os precursores de algo mais: quando iniciei uma revisão de uma das dependências transitivas (
github.com/katzenpost/core/crypto/eddsa ),
o cabeçalho da
licença AGPLv3 me encontrou.
Isso é uma má notícia para quem deseja usar a biblioteca WebAuthn do Duo. Apesar de o Duo licenciar sua biblioteca sob o BSD, escolhendo-a, você também vincula seu aplicativo à biblioteca AGPL. E, de acordo com (A) a GPL, dessa maneira, você cria um produto "modificado" que se enquadra nas regras da
seção 13 da AGPL :
Se você fizer alterações no programa, sua versão modificada deverá oferecer explicitamente a todos os usuários que interagem com ele remotamente pela rede (se sua versão suportar essa interação) a oportunidade de obter acesso gratuito e gratuito ao código fonte da sua versão usando ferramentas de cópia de software padrão (apesar de quaisquer outras disposições desta Licença).
Em outras palavras, se você usou
github.com/duo-labs/webauthn em um aplicativo público da Web, seu aplicativo da Web agora deve ser de código aberto.
A coisa mais ultrajante sobre essa dependência é que ela duplica
golang.org/x/crypto/ed25519 - uma das
bibliotecas "x" quase- padrão do Go.
De fato,
github.com/duo-labs/webauthn é o mesmo que
golang.org/x/crypto/ed25519 originalmente usado. A substituição ocorreu durante uma busca por uma colaboração externa chamada
“Consolidar COSE as coisas para sua própria área” . No processo de transferência de parte do código de um arquivo para outro, essa solicitação de
OKPPublicKeyData.Verify alterou silenciosamente a implementação do
OKPPublicKeyData.Verify .
Aqui está o
OKPPublicKeyData.Verify que usa
golang.org/x/crypto/ed25519 :
E aqui está o
OKPPublicKeyData.Verify , que usa o
github.com/katzenpost/core/crypto/eddsa licenciado pela AGPL:
Nenhuma explicação foi dada para essa mudança. A revisão do pullrequest foi conduzida por
dois funcionários da Duo, aprovada e a reteve.
É por isso que não gosto de aceitar solicitações de recebimento que movam o código. Mesmo que a nova organização do código seja melhor que a anterior, o tempo gasto para verificar "a nova busca por pull faz algo supérfluo" consome muito tempo.
Publiquei um aviso sobre a dependência da biblioteca com a licença AGPL, e os desenvolvedores
retornaram golang.org/x/crypto/ed25519 . Apesar disso, decidi não usar o
github.com/duo-labs/webauthn . A maior parte da biblioteca e suas dependências foram projetadas para oferecer suporte a falhas de funcionalidade do WebAuthn chamadas de atestado, que desejo menos que zero usar. Acabei de escrever uma biblioteca muito mais simples e sem atestados, e ela é menor que um décimo das anteriores. Em breve vou abrir seu código fonte. O desenvolvimento desta biblioteca saiu mais barato do que a responsabilidade de usar a biblioteca WebAuthn Go existente.
Este caso me lembrou porque eu gosto de programar no Go. Graças às extensas bibliotecas padrão e quase-padrão "x" da Go, geralmente há poucas dependências adicionais em meus projetos. E a boa reputação e os procedimentos operacionais do Go permitem que eu não me preocupe e não verifique novamente o código-fonte do compilador e das bibliotecas padrão. E, apesar de amar Rust, fico horrorizado toda vez que olho para a árvore de dependências de suas bibliotecas típicas: geralmente vejo dezenas de dependências transitivas escritas por caras aleatórios obscuros da Internet em que não tenho motivos para confiar. A verificação de todas essas dependências leva muito tempo, por isso sou muito menos produtivo no Rust do que no Go.
Uma observação final: como fã de estruturas de dados verificáveis como a Transparência do certificado, tenho que amar o novo
banco de dados de soma de verificação Go . No entanto, o banco de dados de soma de verificação não será útil se você não gastar tempo checando suas dependências. Infelizmente, eu já vi um usuário Go entusiasmado demais alegando que o banco de dados de soma de verificação resolve todos os problemas com o gerenciamento de dependências. Mas isso não é verdade. Não há maneiras fáceis de se livrar disso, e você precisa aceitar o fato: de tempos em tempos, você precisa fazer análises de dependência em seus projetos.