Preciso criar um novo pacote de snap sempre que uma dependência recebe uma atualização de segurança?

Se eu criar um pacote de snap com digamos 5 dependências. Preciso criar uma nova versão do pacote sempre que uma dependência recebe uma atualização (de segurança)?

Quero dizer, a vantagem dos pacotes .deb é que, no Ubuntu / Debian, por exemplo, posso usar uma biblioteca e, uma vez que a biblioteca recebe uma atualização, isso também significa uma atualização para uma parte do meu software. E como eles enviam apenas atualizações de segurança, posso ter (99%) certeza de que a atualização da biblioteca não interromperá a API para que meu software possa falhar.

— Felix Haller
fonte

A resposta curta é sim, você precisará reconstruir seu snap se precisar atualizar uma dependência. No entanto, há uma resposta mais longa aqui também.

Digamos que você tenha algum aplicativo que use SSL (pode ser um software incorporado ou um site completo usando o Apache). Você faz sua pesquisa e utiliza algoritmos simétricos e de troca de chaves específicos. Agora, digamos que uma vulnerabilidade de segurança foi descoberta no SSL e uma nova versão foi lançada. Só porque é uma versão de segurança, não significa que a vulnerabilidade corrigida estava em um dos algoritmos que você usou. E se não fosse? E se, corrigindo essa vulnerabilidade em um algoritmo que você não usou, algo que você fezuso foi quebrado ou comprometido (aconteceu comigo recentemente com PHP)? Se você o agrupar, poderá telefonar para saber se precisa ou não atualizar de acordo com o uso. Você também pode testá-lo extensivamente antes de lançá-lo para todos os seus usuários. Há também a possibilidade de que a distribuição que você está direcionando tenha uma versão diferente do SSL que não funcione com o seu software, em que agrupá-lo rapidamente fornece uma experiência comum entre plataformas.

Definitivamente, existe uma troca entre os benefícios de compartilhar dependências e os benefícios de agrupá-las.

— Kyle
fonte

Você respondeu algumas perguntas rápidas recentemente, com algum grau de autoridade. Você é um desenvolvedor? Caso contrário, você pode vincular a fontes confiáveis? Se sim, você pode criar algumas fontes confiáveis?

— Muru

(Além disso: se eu tiver que confiar no julgamento e no entendimento de todos os desenvolvedores sobre o código OpenSSL, em vez de, digamos, na equipe de segurança Canonical ou na dos mantenedores Debian que lidam com o OpenSSL há anos, falar em segurança instantânea é um monte de besteira. )

— muru

Se você instalar um software de um desenvolvedor, estará confiando nesse desenvolvedor. A questão de como eles lidam com SSL é um bom exemplo - apenas ter uma versão corrigida de uma biblioteca não ajuda se o desenvolvedor de aplicativos não usar a biblioteca com sabedoria. Existem muitos exemplos de aplicativos com segurança ruim devido a más escolhas de algoritmos, gerenciamento de chaves ou verificação de assinaturas - nada a ver com a versão do OpenSSL à qual eles se vincularam. É prudente entender isso - você não obtém segurança magicamente ao obter uma nova biblioteca em seu sistema.

— Mark Shuttleworth

Por outro lado, se um aplicativo estiver comprometido, uma deb normalmente deixará o invasor percorrer todo o sistema, enquanto um estalo não. Nenhum sistema é perfeito, mas é razoável dizer que os snaps são uma melhoria útil em alguns casos.

— Mark Shuttleworth

@ MarkShuttleworth Eu posso confiar no dev X para entregar um aplicativo decente no idioma Y, mas talvez eu não confie neles para entender se um patch específico para o OpenSSL pode causar problemas para eles, e me parece que é isso que os snaps exigem deles. Esse é um nível de detalhe técnico que eu realmente não acho que a maioria dos desenvolvedores de aplicativos se sinta confortável, e é por isso que eles (e usuários) confiam em bibliotecas como o OpenSSL e em distribuições como o Ubuntu. Claro, eu não sou ninguém, então minha opinião não conta. (Além disso, estalos pode ser confinado, isso não significa que eles não manipular dados do usuário, ...

— Muru