Como posso verificar se instalei software não-livre?

6

Estou pensando em um programa que examina pacotes e relata algumas estatísticas sobre eles - e relata todos os pacotes que contêm software não-livre.

Teria, claro, que incluir módulos do kernel, drivers e outros blobs binários que são freqüentemente permitidos em distribuições. Quanto maior o escopo da pesquisa, melhor.

Eu gostaria dessa funcionalidade no Fedora, mas algo que funciona na maioria das distribuições seria o preferido.

    
por jcora 16.07.2013 / 13:23

2 respostas

3

Esta é uma espécie de resposta indireta, porque não vejo por que você teria software não-livre no sistema e não saberia sobre isso. Isso não quer dizer que você está errado em querer checar, mas talvez primeiro você queira parar e pensar se realmente precisa.

I'd like this functionality on Fedora

Os repositórios do Fedora são divididos em 'livres' e 'não-livres'. Por padrão, apenas os repositórios gratuitos são usados. Então, se você nunca adicionou nenhum outro repositório, então yum não pode ter instalado nada deles.

It would of course have to include kernel modules, drivers and other binary blobs that are often allowed in distributions.

Veja esta página . A única exceção que o fedora faz é para "firmware binário", que não é necessário, a menos que você esteja usando determinado hardware. Eu acho que você também saberia disso, mas eu não posso prometer.

Acredito que "firmware" esteja tecnicamente instalado em um dispositivo e, tecnicamente, ele já está lá de qualquer maneira. Por exemplo, o seu BIOS executa software não-livre. Nesse nível não há nada que você possa fazer. Você também pode ler a discussão do fedora sobre "firmware binário" através do link nessa página.

O próprio kernel não pode conter código não-livre, ele só pode acabar em um módulo. Se você baixar o código fonte do kernel.org e compilar o seu próprio, eu não acho que ele contenha nada desse tipo, já que A atitude de Linus (" Eu aceito-os, mas nunca os apoio e não gosto deles ") implica que módulos não-livres podem ser usados com o kernel mas muito improvável de ser distribuído pelo próprio Linux (isto é, kernel.org). Os drivers proprietários são distribuídos independentemente; distros, em seguida, incluí-los, não kernel.org (no entanto, de acordo com a página "Itens Proibidos", o fedora explicitamente não inclui drivers proprietários, pelo menos nos repos 'livres' padrão).

Você pode investigar on-line todas as informações listadas por lsmod . Como qualquer blob binário tem que ser um módulo, acho que é onde você o encontrará.

O Fedora recomenda que, se você quiser construir seu próprio kernel, você use um pacote fonte deles. No entanto, eu usei kernels enrolados manualmente de fontes vanilla kernel.org no fedora por anos e nunca tive um problema. Então, se você estiver confortável fazendo isso e não usar repositórios não-livres, você não deve ter nenhum material não-livre instalado.

    
por 16.07.2013 / 14:19
3

Independentemente de Kernels e módulos

Ordenação de pacotes:

Isso é testado nos sistemas Mageia / Redhat, etc.

1. Receba todas as licenças usadas de todos os seus pacotes.

rpm -qia | grep "License" | sort

2. Descubra qual licença não corresponde às suas necessidades

3. Descubra qual pacote está usando a licença problemática

rpm -qia | grep ": Problematic License" -A 15 -B 20

Notas:

O vrms (para o debian) e outras ferramentas similares são boas em teoria, mas quando se trata da realidade elas são inúteis, você tem que verificar tudo sozinho se você é um profissional de segurança / privacidade

Nota 2:

Hoje em dia é muito difícil conseguir um sistema totalmente aberto, respeitando a privacidade etc., mas ainda assim é sempre possível, você precisará:

  • Uma máquina com bios de código aberto *

  • Consiga uma boa distro como mageia ou algo assim

  • Verifique todos os pacotes e módulos

  • Compile seu próprio kernel

Nota * máquina com bios de código aberto não existe para o mercado de massa, mas ainda graças a Deus ainda poderíamos executar um bios de código aberto em massa compatível máquinas de mercado piscando a bios nativa.

Um último problema remanescente são os microcódigos de fontes fechadas programados nos chips de máquina. Não podemos fazer muito sobre isso, já que apenas grandes empresas comerciais estão fabricando os hardwares, poderíamos verificar seu funcionamento no fluxo com alguma solução de software ( não é uma tarefa fácil).

Estas ferramentas de kernel relacionadas podem interessá-lo

link

link

    
por 05.08.2015 / 16:11