Há algo de errado em NÃO assinar um assembly .NET?

Um dos meus colegas está muito interessado em assinar assembleias. Ele literalmente tenta assinar qualquer coisa. Mesmo quando usamos assemblies da Microsoft que não são assinados, ele pega o código-fonte, assina-o e pede a outros desenvolvedores que usem sua cópia.

Posso entender a ideia básica por trás da assinatura de um assembly: garantir que um determinado assembly não seja comprometido por algum hacker desonesto. Portanto, se somos uma empresa de desenvolvimento de software, devemos assinar nosso conjunto antes de liberar alguma biblioteca .NET para nossos clientes.

No entanto, desenvolvemos principalmente aplicativos da web para nosso próprio uso aqui, e simplesmente não consigo ver o motivo de assinar cada um dos conjuntos que usamos.

Estou faltando alguma coisa aqui?

Assinar assemblies que são usados ​​em um ambiente confiável soa como um exagero para mim.

Um ponto interessante sobre assemblies assinados é que eles são ligeiramente mais lentos para carregar do que assemblies não assinados, pois eles devem ser verificados criptograficamente.

Para assinar uma assembleia, todas as assembleias da qual depende também devem ser assinadas. Meu palpite é que isso contribui para o desejo do seu colega de assinar tudo - o compilador está exigindo isso.

EDITAR Desde que escreveu esta resposta, você pode ver que os pró e contra o acampamento têm suporte aproximadamente equivalente. Claramente não há uma resposta certa aqui.

O ponto que motivou esta edição é que hoje em dia pegamos muitas bibliotecas de código aberto do NuGet, e muitas delas não são assinadas. Se você quiser assinar seu assembly, também precisará ter todas as dependências assinadas. Muitas das bibliotecas de código aberto assinadas têm as chaves privadas usadas para assinatura disponíveis publicamente em seus repositórios de origem.

Como em tudo, há trocas a serem feitas. Na minha experiência de trabalho em ambientes privados, os benefícios de assinar são principalmente teóricos (ou acadêmicos, como @ user289100 menciona), a menos que você esteja preocupado com agências governamentais modificando seu código. Nesse caso, você precisa ser paranóico com tantos níveis de sua infraestrutura essa assinatura pareceria um pequeno esforço. Caso contrário, a quantidade de desafios que resultam de ter que assinar tudo simplesmente não parece valer a pena. No entanto, seu ambiente pode ter requisitos diferentes, ou você pode ser um masoquista!

Consulte também a resposta de Teun D para obter informações sobre os desafios relacionados aos assemblies de controle de versão ao usar nomes fortes.

Aproveitei as montagens não assinadas para contornar problemas antes e, em ambientes acadêmicos, mostrei às pessoas por que é importante. Substituí um arquivo DLL que não estava assinado (novamente em um ambiente acadêmico) por um que fiz com o mesmo nome, as mesmas assinaturas e usei o .NET Reflector para copiar e colar o código original, mas no meu enviei nomes de usuário e senhas que estavam sendo passados ​​antes de chamar o código 'real'.

Se assinado, você pode fazer uma correspondência de assinatura, mas não substituir. Ao contrário do que diz Zippy, haverá um erro de compliação do tempo de execução.

Assinar assembléias nunca é exagero. Demora 30 segundos. É como dizer que trancar as portas é um exagero se você mora no campo. Se você quer jogar com seus pertences, vá em frente, deixe aberto. Leva apenas uma violação de segurança para ser demitido. Leva apenas 30 segundos para assinar uma assembleia e não há caso de negócios para não fazê-lo. Os impactos no desempenho são insignificantes.

Um ponto adicional: assinar seus assemblies quebra a compatibilidade com versões anteriores. Todas as suas referências começam a incluir números de versão e versões com outros números de versão são consideradas não compatíveis. Isso impede a atualização para versões mais recentes de assemblies distribuídos.

Na minha opinião, você só deve assinar conjuntos de código se perceber algum ganho concreto com isso:

• se você implantar em ambientes onde pessoas não confiáveis ​​podem tocar seus conjuntos
• em certos modelos de plug-in, onde você deseja usar o certificado como evidência para atualizar a confiança
• se o seu código deve ser chamado de outro código assinado (um projeto como, digamos, log4net, assina justificadamente seu código para ser amplamente utilizável; eles bagunçaram enormemente a compatibilidade ao perderem sua chave secreta há alguns anos, outro risco de assinatura de código) .
• se você deseja implantar no GAC

Seu colega lhe deu alguma indicação de por que gosta de assinar assembléias? Uma vantagem da assinatura que ainda não foi discutida aqui é que apenas assemblies assinados podem ser colocados no GAC (ou seja, ser compartilhados entre processos gerenciados), mas as desvantagens parecem superar as desvantagens da minha perspectiva (reconhecidamente inexperiente).

Sua anedota sobre código Microsoft autoassinado parece particularmente suspeito para mim. Se a MS não assinou o código, provavelmente há um motivo, certo? E ao assiná-lo, você está assumindo a responsabilidade por ele quando não o escreveu - outra oportunidade para o futuro morder você.

Outra coisa sobre a assinatura de uma assembléia é que não se pode injetar uma incorreta no lugar da sua (também - você por acidente). Por exemplo, se você criar um programa que se refere a um assembly Foo.dll, versão 1.0, alguém pode criar um assembly, com a mesma versão, e substituir o seu, ao assinar sua biblioteca, isso não será possível (em pelo menos não acho que seja facilmente possível).

As assinaturas só são necessárias se os assemblies forem colocados no GAC, nada mais. Os conjuntos assinados não impedem que alguém mexa com eles. Um hacker ainda pode retirar a assinatura e qualquer outro código que verifique a assinatura.

Eu concordo que parece um desperdício. É realmente necessário para garantir que o arquivo é o que você pensa que é (e não foi adulterado). Mas se você confia nos limites de sua própria segurança de rede e servidor web, então assinar seus assemblies web parece uma etapa redundante.

Mas talvez seja minha experiência em pequenas empresas falando. Se você está falando sobre um site de banco on-line de missão crítica, assine agora.

Pense em fazer isso se você for enviar algo e / ou realmente tiver um motivo para fazê-lo. Em todos os outros casos, é apenas incômodo. Eu perguntaria ao seu colega de trabalho o que ele realmente ganha com isso.

Já encontrei assembleias assinadas antes e é uma dor de cabeça, especialmente quando você considera a quantidade de pessoas que têm pouco ou nenhum conhecimento sobre como assinar assembleias, para que serve e como fazê-lo. É apenas outra coisa com a qual você não deveria se preocupar, a menos que seja absolutamente necessário.

Você precisa assinar seu assembly quando ele for usado em um ClickOnce XBAP de implantação da web .

Além disso, todos os assemblies referenciados precisarão ser assinados também.

Assinamos nossos assemblies porque há momentos em que recebemos erros como o seguinte (este é de teste, mas pode ocorrer durante a execução do aplicativo):

System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Descobrimos que o Visual Studio se engana às vezes e executa código antigo .

Se você deseja um erro se estiver executando um código antigo, assine seus assemblies.

Se você estiver escrevendo um pacote nuget , assine seus assemblies . Assemblies não assinados são estranhos para nós que queremos ter certeza de que estamos executando a versão mais recente do nosso código. Não consigo consertar o Visual Studio . Tudo o que posso fazer é detectar que o Visual Studio errou. Então, por favor, assine seus conjuntos de nuget .