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

Recompilei minhas aulas como de costume e de repente recebi a seguinte mensagem de erro. Por quê? Como posso corrigir isso?

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

Isso acontece quando classes pertencentes ao mesmo pacote são carregadas de arquivos JAR diferentes e esses arquivos JAR têm assinaturas assinadas com certificados diferentes - ou, talvez com mais freqüência, pelo menos um seja assinado e um ou mais outros não (o que inclui classes carregadas dos diretórios, pois esses AFAIK não podem ser assinados).

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

Uma maneira simples de contornar isso é apenas tentar alterar a ordem dos arquivos jar importados, o que pode ser feito no (Eclipse). Clique com o botão direito do mouse no seu pacote -> Caminho da Construção -> Configurar Caminho da Construção -> Referências e Bibliotecas -> Solicitar e Exportar. Tente alterar a ordem dos jarros que contêm arquivos de assinatura.

R. Se você usa o maven, uma maneira útil de depurar frascos colidindo é:

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 classes 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 servlet-api 2.5 em conflito e javax.servlet 3.0.0.x.

B. Outras dicas úteis (como depurar a exceção de segurança e como excluir os deuses) estão na pergunta em Informações do Signatário não coincidem .

No meu caso, eu havia duplicado a versão JAR do BouncyCastle no caminho da minha biblioteca: S

Eu tive uma exceção semelhante:

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

O principal problema foi que eu incluí a biblioteca Hamcrest duas vezes. Uma vez usando o arquivo pom Maven. 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 da compilação e tudo estava bem.

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 de assinante da classe de destino do aplicativo.

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

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

1. Salve o arquivo
2. Feche novamente
3. Renaime ext para .jar voltar
4. Já

Se você estiver executando no Eclipse, verifique os jars de qualquer projeto adicionado ao caminho de construção; ou controle-shift-T e verifique se há vários frascos correspondentes ao mesmo espaço para nome. Em seguida, remova os jarros redundantes ou desatualizados do caminho de construção do projeto.

Estou tendo esse problema com o Eclipse e o JUnit 5. Minha solução é inspirada na resposta anterior do usuário2066936 É para reconfigurar a ordem das bibliotecas de importação:

1. Clique com o botão direito do mouse no projeto.
2. Abra [Caminho de Construção Java].
3. Clique em Order and Export.
4. Em seguida, pressione JUNIT para prioridade máxima.

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.

Um tópico muito antigo, mas desde que fiquei preso por algum tempo nisso, aqui está a correção (espero que ajude alguém)

Meu cenário:

O nome do pacote é: com.abc.def. Existem 2 arquivos jar que contêm classes deste pacote, como jar1 e jar2, ou seja, algumas classes estão presentes no jar1 e outras no jar2. Esses arquivos jar são assinados usando o mesmo keystore, mas em momentos diferentes na compilação (ou seja, separadamente). Isso parece resultar em uma assinatura diferente para os arquivos em jar1 e jar2.

Coloquei todos os arquivos no jar1 e os construí (e assinei) juntos. O problema desaparece.

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

Se você adicionou todos os jars do bouncycastle.org (no meu caso, do crypto-159.zip), remova os dos JDKs que não se aplicam a você. Existem despedimentos. Você provavelmente só precisa dos frascos "jdk15on".

Essa pergunta durou muito tempo, mas eu quero discutir alguma coisa. Eu tenho trabalhado em um desafio do projeto Spring e descobri isso no Eclipse IDE. Se você estiver usando as APIs Maven ou Gradle para Spring Boot Rest, precisará remover o Junit 4 ou 5 no caminho da construção e incluir o Junit no seu arquivo de construção pom.xml ou Gradle. Eu acho que isso se aplica ao arquivo de configuração yml também.

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

Eu poderia consertar isso.

Causa raiz: Esse é um problema comum ao usar a implementação Sun JAXB com jars assinados. Essencialmente, a implementação do JAXB está tentando evitar a reflexão gerando uma classe para acessar diretamente as propriedades sem usar a reflexão. Infelizmente, ele gera essa nova classe no mesmo pacote que a classe que está sendo acessada e é daí que 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 do @Mohit Phougat, se você estiver executando um Groovy com anotações do @Grab, poderá tentar reordenar essas anotações.

isso aconteceu comigo ao usar JUnit + tenha certeza + hamcrest, neste caso, não adicione junit para criar o caminho, se você tiver o projeto maven, isso me resolveu, abaixo está o pom.xml

<dependencies>

    <dependency>
        <groupId>io.rest-assured</groupId>
        <artifactId>rest-assured</artifactId>
        <version>3.0.0</version>
    </dependency>

    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-all</artifactId>
        <version>1.3</version>
    </dependency>


    <!-- https://mvnrepository.com/artifact/junit/junit -->
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>

    </dependency>


</dependencies>

Eu estava executando o JUNIT 5 e também estava fazendo referência ao jar externo Hamcrest. Mas Hamcrest também faz parte da biblioteca JUNIT 5 . Portanto, eu tenho que alterar a ordem do arquivo jar externo Hamecrest na biblioteca JUNIT 5 no caminho de construção.