Como você verifica as bibliotecas de código aberto em busca de registradores de pressionamento de tecla?

Uma pessoa aleatória na internet me disse que uma tecnologia era segura (1), segura de usar e não continha keyloggers por ser de código aberto. Embora eu possa detectar trivialmente o registrador de pressionamentos de teclas nesse aplicativo de código-fonte aberto , o que os desenvolvedores (2) podem fazer para se proteger contra comprometedores rouge em projetos de código-fonte aberto?

Fazendo uma análise detalhada das ameaças em envelope, se eu fosse um desenvolvedor desonesto, faria uma divisão no git e promoveria o download, pois ele teria suporte ao twitter (e um registrador de pressionamento de tecla secreto). Se fosse um repositório SVN, eu criaria apenas criar um novo projeto. Melhor ainda seria colocar o código malicioso nas rotinas de atualização automática.

(1) Não vou mencionar isso porque só posso lidar com um tipo de fanático por vez.

(2) Usuários comuns estão à mercê de seu software de detecção de vírus e malware - é absurdo esperar que a avó leia a fonte do código do código-fonte do processador de texto de código-fonte aberto para encontrar o registrador de pressionamentos de tecla.

Recentemente, tive a oportunidade de realizar uma análise de segurança de software no FileZilla, eMule e Shareaza. Eu executei o código através do cppcheck, RATS e ITS4. Nenhuma ferramenta será capaz de discernir se um pedaço de código é benigno ou prejudicial. Requer inspeção visual - foi o que eu fiz. Passei duas semanas examinando linha por linha cada parte do código-fonte. Eu provavelmente perdi alguma coisa. É por isso que meu trabalho foi apoiado por outra pessoa que também encontrou o mesmo ou mais do que eu. Por exemplo, o FileZilla utiliza um script PHP para determinar seu endereço IP externo no modo PASV. O que esse script PHP faz? Quem realmente sabe? Eu vejo o seu ponto e ponto bem entendido. Dependendo da sua estratégia, você deve adotar uma estratégia de mitigação de riscos e examinar a fonte por conta própria ou contratar consultores externos. Dessa forma, você garantirá que o software esteja seguro.

Isso se enquadra na categoria "confie nele, seu código aberto". Se um número suficiente de pessoas estiver visualizando o código de um projeto, é improvável que alguém possa usar algo nefasto. Além disso, observe a reputação da parte que está apoiando o projeto. É J. Random Coder, ou Apache Software Foundation? Obviamente, quanto menor a base de código, mais difícil é inserir algo. E o projeto de código aberto depende de bibliotecas externas que não sejam de código aberto? Se um projeto é uma ramificação personalizada de um projeto obscuro hospedado em um site desconhecido ... bem.

Além disso, eu não me preocuparia especificamente com keyloggers, mas com mais segurança em geral. Isso inclui violações acidentais de segurança, com maior probabilidade de ocorrerem em um projeto pequeno. Backdoors, privacidade mal implementada e acesso necessário ao sistema são todos os riscos mais prováveis ​​do que um keylogger intencional.

Os desenvolvedores podem impedir comprometedores desonestos em seus projetos de código aberto, não concedendo privilégios a todos e seus pingüins. O princípio distintivo do Software Livre / Código Aberto não é que o desenvolvimento seja de origem coletiva (embora possa ser), mas que é possível dividir projetos.

As pessoas que estão baixando software precisam executar um pouco de cuidado, e isso é verdade tanto para o F / OSS quanto para o software proprietário / de código fechado. O software que você obtém de uma fonte respeitável geralmente é bom (em ambos os casos); É mais provável que o software de um voo noturno tenha malware.

Não é como se alguém tivesse acesso a qualquer projeto de código aberto. E mesmo que alguém cometa código malicioso, ele pode ser descoberto, pois a fonte é pública. Se você não confia nos gerentes do projeto, sempre pode contratar alguém como 0A0D para inspecionar o código. Não é perfeito, mas é melhor que a alternativa;

Para um projeto de código fechado, basta confiar no fornecedor. Como você sabe que não há backdoors no software de código fechado? Você não Código malicioso pode ter sido adicionado por um funcionário insatisfeito, alguém procurando uma maneira de ganhar dinheiro, um zelador malvado que por acaso teve acesso ao repositório da empresa ... No software de código fechado, não há como saber.