Como faço para verificar se um pacote grande em um repositório git é seguro?

Estou olhando o emacs helm especificamente, que possui as seguintes propriedades:

tem milhares de commits
é amplamente mantido por um usuário
o mantenedor não possui outros perfis (mídias sociais etc.) que encontrei em algumas pesquisas
é mantido ativamente (hoje)

Como estou prestes a instalar um código arbitrário no meu computador para usar no meu editor de texto, eu queria verificar se isso passou por algum processo de revisão. Eu gostaria de dizer "bem, é de código aberto", mas realmente estou longe da capacidade da elisp de auditar todo o código. Eu gostaria de assumir que outros membros da comunidade o revisaram, mas um que provavelmente é falso e dois existem confirmações atualizadas. Faltam outras estratégias?

Para o registro, o vetor é simples: "código aberto" não importa muito se o colaborador estiver trabalhando em uma conta descartável ou se não houver um processo de revisão.

— djechlin
fonte

" Verificar " é uma palavra grande. No sentido regular da palavra, acho que a resposta é: "Você não precisa (não pode)". Você pode acompanhar a atividade de desenvolvimento de uma biblioteca e verificar assinaturas digitais e tal, mas acredito que não há nada certo e certo.

— Desenhou

Boa pergunta. FWIW, o código que acompanha o Emacs é revisado (através da lista de discussão emacs-diffs), mas se algum colaborador adicionar uma falha de segurança, tenho certeza de que ele será capaz de fazer isso sem ser notado. Obviamente, eu ficaria surpreso se já não houvesse muitas falhas de segurança acidentais no Emacs, então não tenho certeza de quanto isso pode ser um problema. Então, para poder obter uma resposta mais tranquilizadora, é preciso focar em ameaças simples e simples (por exemplo, deve ser bastante fácil verificar se o código executa algum tipo de vigilância não oculta).

— Stefan

O mantenedor está ativo no emacs devel por muitos anos, o que pode ser verificado com uma pesquisa, portanto, essa é uma garantia: lists.gnu.org/archive/cgi-bin/…

— Tom

@ Stefan, eu estava pensando em apenas uma verificação no local. Do meu ponto de vista, mapatomspoderia ser colocado no grupo "perigoso" junto com start-process, evale funcall. É claro que haveria alguns falsos positivos, mas se o pacote não usar nenhuma dessas funções, poderá ser marcado como inofensivo com grande certeza.

— abo-abo

Você precisa adicionar o novo make-process, bem como call-process, dbus-<foo>, make-network-stream, e, em seguida vc-do-command, vc-git-command, .... E se você colocar evale funcallna categoria "perigoso", então a maioria / todos os pacotes são perigosos.

— Stefan

A resposta curta é: a menos que você mesmo leia o código, estará confiando bastante. Dito isto, confiar em um projeto proveniente de um SCM upstream é um pouco mais seguro do que aquele que foi extraído diretamente do Emacs Wiki, por exemplo. No entanto, fundamentalmente, você confia no autor do pacote para não se tornar mal e abusar da capacidade de executar código arbitrário na sua sessão do Emacs.

Existem algumas coisas que podem fazer você se sentir mais seguro:

Atenha-se a pacotes populares

Embora os pacotes populares não sejam revisados automaticamente, o fato de terem mais usuários significa que as chances de um comportamento malicioso ser detectado antes de afetá-lo aumentam.

Veja as métricas de código

No github, você pode ter uma visão bastante boa do histórico de contribuições dos projetos. Mesmo que o autor principal faça a maioria dos commits com uma ampla variedade de autores, mostre que há outras pessoas com um interesse ativo na estabilidade e na eficácia do código.

Prefira GNU ELPA e MELPA Stable a repositórios que rastreiam HEADs (MELPA) ou permitam envios sem verificação (Marmalade)

Embora morar no limite tenha um certo apelo para quem deseja os mais recentes recursos brilhantes, significa que você pode ser o primeiro a aceitar o último comprometimento em seu ambiente. Mesmo que não seja malicioso, você pode obter um pacote em um estado de fluxo, enquanto uma versão "oficial" terá pelo menos algum tipo de revisão superficial. Por exemplo, os pacotes GNU ELPA serão confirmados apenas pelos usuários do emacs-devel com direitos de confirmação.

Por fim, tenho certeza de que, em algum momento, haverá uma violação de segurança através do sistema de pacotes, mesmo que seja apenas uma prova de experimento de conceito. Esse será o ponto em que você precisará confiar em seus backups regulares.

— stsquad
fonte

Marmalade é um arquivo ruim quando se trata de "confiança". Ele permite que qualquer pessoa faça o upload de pacotes com qualquer nome, com zero verificação ou revisão. E não é exatamente bem conservado (basta olhar para o número de questões em aberto).

— Lunaryorn 28/05

@ lunaryorn: bom ponto, vou alterar a resposta.

— Stsquad 28/05

@lunaryorn O MELPA tem problemas ainda mais abertos do que o repositório elmarmalade, por isso duvido que seja uma métrica utilizável.

— Wasamasa 28/05

@stsquad A única coisa que o MELPA Stable oferece a você é lançamentos marcados de coisas que acabariam no MELPA, então não vejo como isso é mais seguro do que usar o Marmalade.

— Wasamasa 28/05

@wasamasa Desculpe, meu comentário foi mal formulado. O número não diz muito, com certeza, mas as questões em aberto são reveladoras: não há reação em relação a novas questões, nenhum comentário, nem mesmo rótulos ou atribuições. Marmelada está efetivamente morta.

— Lunaryorn