É seguro instalar programas que não sejam do gerenciador de pacotes de uma distribuição?

Em termos gerais, sim, é seguro — desde que qualquer coisa instalada que não use um pacote seja instalada em /usr/localou /opte não se adicione aos arquivos de configuração global do sistema .

Abordarei a última parte da sua pergunta primeiro porque é mais simples. Se você baixar um .debarquivo e instalá-lo (usando apt install ./minecraft.debpor exemplo, que é melhor do que dpkg -i minecraft.debporque ele cuidará das dependências para você), o gerenciador de pacotes estará ciente do pacote. Isso é bom porque significa que as dependências do pacote não serão removidas acidentalmente. Você também poderá desinstalar o pacote usando apt. No entanto, instalar um pacote dessa maneira não garante necessariamente que você será capaz de atualizá-lo com apt; a exceção são os pacotes que configuram seu próprio repositório ( por exemplo, muitos pacotes do Google). Você sempre pode atualizar manualmente esses pacotes baixando um novo pacote e usando apt installnovamente para instalá-lo.

Ecossistemas de linguagem e ferramentas associadas como rustupsão um pouco mais complexos. Só para sair rustupdo caminho, ele está disponível como um pacote Debian, mas apenas no Debian 13 e posteriores (veja o rustupmanual de instalação ); então você não pode usar apt install rustupcomo está no Debian 12.

A maioria dos ecossistemas de linguagem está ciente das restrições de empacotamento de distribuição e funciona bem junto com os pacotes na distribuição. Você pode instalar a versão mais recente do Go, por exemplo, junto com o Go empacotado no Debian, e tudo funcionará bem. O mesmo vale para Java e, desde o Debian 12, Python, desde que você use ambientes virtuais. As únicas coisas das quais você precisa ter certeza absoluta é que você nunca substitua os binários do sistema (aqueles em /usr/bin) por versões incompatíveis; isso é especialmente comum com Python, e há muitas perguntas aqui surgindo de usuários substituindo /usr/bin/python3. Contanto que você não faça algo assim, você deve ficar bem.

Software instalado fora do gerenciador de pacotes geralmente não é rastreado por ele.

Instalar software manualmente pode levar a conflitos com pacotes instalados por meio do gerenciador de pacotes. Se o software instalado manualmente depender de versões específicas de bibliotecas ou ferramentas, isso pode entrar em conflito com versões gerenciadas pelo seu gerenciador de pacotes.

Se você instalar o software manualmente a partir da fonte ou por meio de um script, precisará seguir as instruções de desinstalação fornecidas pelo software, que pode não se integrar ao seu gerenciador de pacotes.

Sempre que possível, use o gerenciador de pacotes da sua distro. Ele simplifica atualizações e gerenciamento de dependências.

.debo pacote pode ser instalado com dpkgouapt

Como instalar um arquivo deb, pelo dpkg -i ou pelo apt?

sudo apt install package.deb

sudo dpkg -i package.deb

dpkgé uma ferramenta de gerenciamento de pacotes de baixo nível para sistemas baseados em Debian que instala, remove e gerencia .debpacotes diretamente.

Tente usar repositórios Debian se possível.

Não se esqueça, nem todos os pacotes estão nos repositórios principais contrib do Debian.

Você tem que modificar seu/etc/apt/sources.list

Este é meu sources.list:

## MAIN STABLE
deb http://deb.debian.org/debian bookworm main
deb-src http://deb.debian.org/debian bookworm main

deb http://deb.debian.org/debian-security/ bookworm-security main
deb-src http://deb.debian.org/debian-security/ bookworm-security main

deb http://deb.debian.org/debian bookworm-updates main
deb-src http://deb.debian.org/debian bookworm-updates main

## NON-FREE
#deb http://deb.debian.org/debian bookworm main non-free-firmware
#deb-src http://deb.debian.org/debian bookworm main non-free-firmware

#deb http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware
#deb-src http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware

#deb http://deb.debian.org/debian bookworm-updates main non-free-firmware
#deb-src http://deb.debian.org/debian bookworm-updates main non-free-firmware

## BACKPORTS
#deb http://deb.debian.org/debian bookworm-backports main contrib non-free
#deb-src http://deb.debian.org/debian bookworm-backports main contrib non-free

## UNSTABLE
#deb http://deb.debian.org/debian/ unstable main
#deb-src http://deb.debian.org/debian/ unstable main

Após fazer a alteração, execute sudo apt-get updateou apt updatepara atualizar a lista de pacotes.

Qual é a diferença entre apt e apt-get?

Só para você saber, há outro gerenciador de pacotes chamado Synaptic.

É um graphical frontendpara apte dpkgque fornece uma interface amigável.

Os usuários podem pesquisar pacotes, visualizar informações sobre eles e instalá-los ou removê-los com um clique.

Ele exibe dependências e pacotes sugeridos, dando ao usuário mais controle sobre o gerenciamento de pacotes.

Synaptic é uma interface gráfica para o sistema de gerenciamento de pacotes Debian.

Geralmente não é possível responder a essa pergunta, pois não sabemos o que a instalação envolve, especialmente quando instalamos algo por meio de um comando como este:

 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

O script pode estar fazendo qualquer coisa. Pode estar adicionando um repositório e instalando algo daquele repositório (e há muitos curl | shscripts que fazem isso). Pode aparecer como scripts diferentes em locais diferentes (provavelmente não aparece aqui, mas pode ) . Aquele pacote deb do minecraft pode estar adicionando um repositório. Qualquer um deles pode muito bem quebrar os sistemas de gerenciamento de pacotes (se eles os usarem, no caso de curl | shscripts), se eles adicionarem um repositório que então adicione algum pacote que sombreie ou entre em conflito com algum outro pacote que você queira usar dos repositórios da distro.

E não apenas arquivos deb ou scripts aleatórios. Instalar pacotes Python arbitrários como root (o que o script pode estar fazendo) é conhecido por quebrar sistemas de gerenciamento de pacotes, e é por isso que o PEP-668 surgiu (levando a postagens como erro pip no Ubuntu: externally-managed-environment × Este ambiente é gerenciado externamente e Como resolvo "erro: externally-managed-environment" toda vez que uso o pip 3? ). O script pode estar compilando e instalando o OpenSSL ou alguma biblioteca central desse tipo, e quebrar seus comandos de gerenciamento de pacotes simplesmente porque a biblioteca foi instalada de uma forma que substituiu as bibliotecas do sistema.

No caso dos curl | shscripts, geralmente prefiro analisá-los eu mesmo, extrair as partes que são relevantes para mim e para os sistemas que estou usando e executá-las eu mesmo.

Nesse caso, o pacote seria rastreado pelo gerenciador de pacotes? Eu conseguiria desinstalá-lo ou atualizá-lo com o apt?

Neste caso, sim, o pacote seria rastreado pelo apt/dpkg. Você seria capaz de desinstalá-lo. Alguns arquivos deb (notavelmente o Google Chrome) adicionam repositórios como parte da instalação do pacote, o que permite que você os use aptpara atualizá-los, mas pode ser necessário baixar manualmente novos arquivos deb e instalá-los novamente se nenhum desses repositórios for adicionado.

É impossível ter certeza quando você está efetivamente 'tomando a abordagem do Windows' e baixando e executando algum software aleatório. Alguns são bem comportados e colocarão tudo sob /optou /usr/localcomo necessário para evitar interferir no gerenciador de pacotes do sistema. Como exemplo, a cadeia de ferramentas Go upstream oficial de https://go.dev coloca tudo sob /usr/localem sistemas semelhantes ao UNIX (na verdade /usr/local/go). Mas nem todo software é bem comportado assim, e é difícil ter certeza.

Há algumas exceções especiais para tudo isso:

• Flatpaks são seguros. Eles são projetados especificamente para esse tipo de distribuição de software e são amplamente garantidos para lidar corretamente com as coisas. Em alguns casos, eles são até mesmo preferidos ao gerenciador de pacotes da distro porque funcionam de forma mais confiável (o Steam é um excelente exemplo disso) ou fornecem melhor segurança.
• Snaps e AppImages também são seguros no mesmo sentido que Flatpaks, embora eu geralmente recomende um Flatpak em vez de um Snap ou AppImage (Flatpak geralmente tem menos sobrecarga, melhor integração com desktop e um modelo de permissões mais fácil de trabalhar).
• Contêineres OCI como Docker/Podman são seguros. Novamente, eles são projetados para esse tipo de uso. Na verdade, essas são a abordagem preferida para cadeias de ferramentas como Rust, Elixir, Node.JS ou mesmo Python em muitos casos, pois é muito provável que você queira outras coisas não empacotadas pela sua distro como parte do trabalho com a linguagem.
• Aplicativos/ferramentas escritos em Go são geralmente seguros se instalados usando as ferramentas go ( go install). A cadeia de ferramentas Go gerencia esses aplicativos em um subdiretório do seu diretório home, e eles são essencialmente 100% autocontidos, então quase não há risco envolvido, a menos que eles gravem em arquivos arbitrários no sistema.
• Repositórios de terceiros para o gerenciador de pacotes do sistema são seguros ( especificamente no sentido de que não quebram o gerenciador de pacotes inerentemente), mas podem não funcionar completamente com o sistema.
• Pacotes isolados no formato nativo do sistema são seguros no mesmo sentido que repositórios de terceiros, mas eles tendem a usar atualizações automáticas no estilo do Windows (o Minecraft DEB, por exemplo, apenas garante que os pacotes necessários sejam instalados e então instala uma configuração mínima de bootstrap que baixará o inicializador real do Minecraft, que por sua vez baixará o próprio Minecraft. O Dropbox é conhecido por fazer algo parecido e acho que o Google Chrome também faz), o que tem algumas implicações de segurança potencialmente desagradáveis.

Comparação da segurança da embalagem

Não existe algo como absolutamente seguro ou absolutamente inseguro. É tudo relativo. Mas, falando relativamente, os pacotes de distribuição são geralmente mais seguros por vários motivos. Isso não deve impedi-lo de instalar pacotes de não distribuição quando precisar deles. Mas se um programa estiver disponível como um pacote de distribuição e de outro canal, você deve usar o pacote de distribuição, se possível.

Por “pacote de distribuição”, refiro-me a pacotes distribuídos diretamente por grandes distribuições como Debian, Ubuntu, Red Hat, SuSE, Arch, FreeBSD, etc. Distribuições com menos mão de obra podem ter menos segurança relativa. Pacotes baixados manualmente no formato de distribuição (por exemplo, a .debou .rpm) não têm as vantagens de segurança dos pacotes de distribuição. Pacotes instalados de fontes de pacotes adicionais (por exemplo, Ubuntu PPA) estão no meio.

Transparência

Os pacotes de distribuição são assinados e replicados, e o instalador verifica a assinatura. Então você sabe o que está recebendo. Se um bug for descoberto em uma determinada versão, você pelo menos poderá saber se tinha a versão com bugs.

Em contraste, quando você instala algo com curl https://example.com/run_me.sh | bash, você não tem como saber o que instalou. Eu vi pelo menos uma prova de conceito (não me lembro se foi um ataque real ou não) onde o servidor web retornou um instalador limpo se você baixou o .sh, mas um instalador backdoored se você executou curl … | bash, detectando o tempo de pausas na execução do script do instalador.

Fontes de pacotes de terceiros estão no meio: elas são assinadas apenas por seus fornecedores, mas algumas (como o Ubuntu PPA) são hospedadas por distribuições, o que pelo menos evita substituições não detectadas.

Escrutínio

Softwares enviados por distribuições recebem algum escrutínio. Não é muito, e absolutamente não é algo que possa evitar bugs ou backdoors. Mas é o suficiente para tornar mais difícil enviar um backdoor que não seja detectado por um longo tempo. E isso significa que o software é confiável por pelo menos uma pessoa que é confiável por uma distribuição.

Obter o software diretamente do fornecedor elimina uma camada de escrutínio, não importa se você o obtém de uma fonte de pacote ou de um download de site.

Disponibilidade de atualizações de segurança

Distribuições têm pessoas que fazem atualizações de segurança quando uma vulnerabilidade é descoberta. Isso inclui portar correções de segurança para a versão distribuída do pacote. Exceto com distribuições contínuas, em uma determinada versão da distribuição, você só obtém correções de bugs importantes, então você pode estar razoavelmente confiante de que a versão corrigida não terá novos recursos que interfiram no seu fluxo de trabalho.

Alguns fornecedores seguem os mesmos princípios. Outros não.

Automaticidade das atualizações de segurança

Para qualquer software que venha através do seu gerenciador de pacotes, um único comando (por exemplo, apt update && apt upgrade) aplica todas as atualizações de segurança. Algumas distribuições ou ambientes de desktop configuram tarefas automáticas para aplicar atualizações de segurança, ou para solicitar que você aplique atualizações de segurança.

Para software que vem por outros canais, você tem que lembrar de ir e procurar por atualizações. Então você pode ter software vulnerável por um longo tempo antes de perceber.

Automação de pacotes

A maioria dos sistemas de empacotamento mantém o controle de qual pacote possui quais arquivos. Eles sinalizam um erro se um pacote tenta sobrescrever um arquivo de outro pacote. Eles removem todos os arquivos de um pacote quando você o desinstala. Isso se aplica a qualquer coisa que use o sistema de empacotamento, independentemente de quem fez o pacote.

Você não obtém esses benefícios com software instalado manualmente.

Qualidade da embalagem

As distribuições têm requisitos mínimos de qualidade de pacote. Por exemplo, elas seguem convenções de estrutura de diretório. Elas não vão atrapalhar seu sistema ou sua conta de usuário de maneiras arbitrárias. Elas limpam depois de si mesmas quando você as desinstala.

Softwares de terceiros, sejam eles fornecidos em pacotes ou não, podem ou não atingir essa qualidade.

Qualidade de integração

As distribuições não fazem muitos testes da maioria dos softwares que elas enviam. Mas pelo menos elas garantem que todas as dependências sejam satisfeitas — você não vai acabar com o software B exigindo A versão 1.3, o software C exigindo A versão 1.4, e nenhuma maneira de instalar ambas as versões de A. Em particular, uma dada versão de uma distribuição compila todos os programas contra um dado conjunto de versões de biblioteca. As distribuições resolvem o inferno das DLLs para você.

Se você instalar um software que não seja da distribuição, você estará por conta própria. O fornecedor pode ou não ter testado com um sistema similar ao seu. Dois fornecedores diferentes podem ter expectativas completamente diferentes de um sistema típico.

É por isso que muitos fornecedores agora enviam “appliances”: em vez de apenas enviar um aplicativo, eles enviam o aplicativo e todas as bibliotecas das quais ele depende. Às vezes, eles chegam ao ponto de colocar o aplicativo em um contêiner: flatpak, imagem Docker, máquina virtual... Isso resolve o problema de dependência, mas também significa que as bibliotecas no contêiner não recebem correções de bugs (e em particular correções de segurança) a menos que o fornecedor aplique as correções em sua própria cópia da biblioteca. Na prática, isso nunca acontece, então voltamos ao problema de disponibilidade de atualização de segurança que mencionei acima.

Sobre ecossistemas linguísticos

Se você é um desenvolvedor, em muitas linguagens de programação, canais de distribuição específicos da linguagem ( pip, npm, rustup, hackage, opam, …) são difíceis de evitar.

Infelizmente, o estado do empacotamento é bem ruim. A única coisa boa é que eles lidam com dependências versionadas. Esses gerenciadores de pacotes mal conseguem controlar quais arquivos pertencem a quem. Eles podem ou não conseguir limpar tudo ao desinstalar.

Esses ecossistemas geralmente desistem do inferno das DLLs e apenas dizem para você instalar cópias separadas de tudo em cada uma das suas árvores de construção, ou pelo menos uma por (versão de um) projeto. Mas se seu projeto precisa das bibliotecas A e B, que precisam da biblioteca C, mas em versões diferentes... é uma pena para você.

Então você deve evitar o empacotamento do ecossistema de linguagem se puder, mas frequentemente, não pode. Você precisa gastar algum esforço na revisão e manutenção da sua cadeia de suprimentos.