Java SecurityException: as informações do assinante não correspondem

Eu recompilei minhas aulas como de costume e, de repente, recebi a seguinte mensagem de erro. Por quê? Como posso consertar isso?

java.lang.SecurityException: class "Chinese_English_Dictionary"'s signer information does not match signer information of other classs in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:776) 

Isso acontece quando classs pertencentes ao mesmo pacote são carregadas de arquivos JAR diferentes, e esses arquivos JAR têm assinaturas assinadas com certificados diferentes – ou, talvez mais frequentemente, pelo menos um é assinado e um ou mais outros não são (o que inclui classs carregadas diretórios desde que esses AFAIK não podem ser assinados).

Portanto, certifique-se de que todos os JARs (ou pelo menos aqueles que contêm classs dos mesmos pacotes) sejam assinados usando o mesmo certificado ou remova as assinaturas do manifesto de arquivos JAR com pacotes sobrepostos.

Uma maneira simples de contornar isso é apenas tentar alterar a ordem dos arquivos jar importados que podem ser feitos a partir do (Eclipse). Clique com o botão direito em seu pacote -> Caminho de Construção -> Configurar caminho de construção -> Referências e Bibliotecas -> Pedido e Exportar. Tente alterar a ordem dos jars que contêm arquivos de assinatura.

A. Se você usa maven, uma maneira útil de depurar jarras de choque é:

 mvn dependency:tree 

Por exemplo, para uma exceção:

 java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classs in the same package 

nós fazemos:

 mvn dependency:tree|grep servlet 

Sua saída:

 [INFO] +- javax.servlet:servlet-api:jar:2.5:compile [INFO] +- javax.servlet:jstl:jar:1.2:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp:jar:2.2.0.v201112011158:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:jar:1.2.0.v201105211821:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile [INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.0.RC2:compile 

mostra confronto servlet-api 2.5 e javax.servlet 3.0.0.x.

B. Outras dicas úteis (como depurar a exceção de segurança e como excluir depas de maven) estão na pergunta em As informações do Signatário não correspondem .

No meu caso, eu tinha duplicado a versão JAR do BouncyCastle no meu caminho de biblioteca: S

Isso pode ocorrer com os proxies instrumentados por cglib porque o CGLIB usa suas próprias informações de assinante em vez das informações do assinante da class de destino do aplicativo.

Eu tive uma exceção semelhante:

 java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classs in the same package 

O problema principal era que eu incluí a biblioteca Hamcrest duas vezes. Uma vez usando o arquivo Maven pom. E também adicionei a biblioteca JUnit 4 (que também contém uma biblioteca Hamcrest) ao caminho de construção do projeto. Eu simplesmente tive que remover o JUnit do caminho de construção e estava tudo bem.

  1. Após o sinal, acesse: dist \ lib
  2. Encontre .jar extra
  3. Usando Winrar, você extrai para uma pasta (extrair para a opção “nome da pasta”)
  4. Acesso: META-INF / MANIFEST.MF
  5. Exclua cada assinatura assim:

Nome: net / sf / jasperreports / engine / util / xml / JaxenXPathExecuterFactory.c lass SHA-256-Digest: q3B5wW + hLX / + lP2 + L0 / 6wRVXRHq1mISBo1dkixT6Vxc =

  1. Salve o arquivo
  2. Zip novamente
  3. Renaime ext para .jar de volta

Se você estiver executando no Eclipse, verifique os jars de quaisquer projetos adicionados ao caminho de construção; ou faça o controle-shift-T e procure por vários jars correspondentes ao mesmo namespace. Em seguida, remova os flasks redundantes ou desatualizados do caminho de criação do projeto.

No meu caso, foi um conflito de nome de pacote. O projeto atual e a biblioteca referenciada assinada tinham um pacote em comum package.foo.utils . Apenas alterei o nome do pacote propenso a erros do projeto atual para outra coisa.

Isso também acontece se você include um arquivo com nomes diferentes ou de locais diferentes duas vezes, especialmente se essas forem duas versões diferentes do mesmo arquivo.

Eu poderia consertar isso.

Causa raiz: Este é um problema comum ao usar a implementação Sun JAXB com jars assinados. Essencialmente, a implementação do JAXB está tentando evitar a reflection gerando uma class para acessar diretamente as propriedades sem usar reflection. Infelizmente, ele gera essa nova class no mesmo pacote da class que está sendo acessada, de onde vem esse erro.

Resolução: Inclua a seguinte propriedade do sistema para desativar as otimizações JAXB que não são compatíveis com os jars assinados: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true

Ref: https://access.redhat.com/site/solutions/42149

Com base na resposta @Mohit Phougat, se você estiver executando uma anotação Groovy com @Grab, poderá tentar reordenar essas annotations.

Um segmento muito antigo, mas desde que eu estava preso por algum tempo sobre isso, aqui está a correção (espero que ajude alguém)

Meu cenário:

O nome do pacote é: com.abc.def. Há dois arquivos jar que contêm classs deste pacote, como jar1 e jar2, isto é, algumas classs estão presentes no jar1 e outras no jar2. Esses arquivos jar são assinados usando o mesmo armazenamento de chaves, mas em momentos diferentes na construção (isto é, separadamente). Isso parece resultar em assinatura diferente para os arquivos em jar1 e jar2.

Coloquei todos os arquivos no jar1 e criei (e assinei) todos eles juntos. O problema desaparece.

PS: Os nomes dos pacotes e os nomes dos arquivos jar são apenas exemplos

Se você adicionou todos os jars do bouncycastle.org (no meu caso do crypto-159.zip), apenas remova os que não se aplicam a você. Existem despedimentos. Você provavelmente só precisará dos flasks “jdk15on”.