sendgrid-java
sendgrid-java copied to clipboard
Sign sendgrid-java-x.x.x.jar
Issue Summary
Looks like you should reopen #631.
Can't deploy with sendgrid-java dependency to Google Cloud Functions with error message:"Invalid signature file digest for Manifest main attributes"
Without sendgrid-java it deploys successfully. So the issue is definitely with your artifact or its dependencies.
Steps to Reproduce
Add dependency on sendgrid-java (4.7.0) and try to deploy to Google Cloud Functions with shade plugin.
Here is shade plugin Maven config:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<outputFile>${project.build.directory}/deployment/${project.build.finalName}.jar
</outputFile>
<transformers>
<!-- This may be needed if you need to shade a signed JAR -->
<transformer
implementation="org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer">
<resource>.SF</resource>
<resource>.DSA</resource>
<resource>.RSA</resource>
</transformer>
<!-- This is needed if you have dependencies that use Service Loader. Most Google Cloud client libraries does. -->
<transformer implementation=
"org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
Technical details:
- sendgrid-java version: 4.7.0
- java version: 11
@thinkingserious please take a look
Hello @artieshevchenko,
Thanks for taking the time to report this!
I just downloaded the most recent jar from Maven and ran jarsigner -verify ~/Downloads/sendgrid-java-4.7.1.jar and the return value was jar is unsigned.
This issue has been added to our internal backlog to be prioritized. Pull requests and +1s on the issue summary will help it move up the backlog. In the mean time, here may be a work around.
With best regards,
Elmer
I have also experienced this issue with the sendgrid-java.jar with all of the dependencies.
$ jarsigner -verify sendgrid-java.jar
jarsigner: java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
The problem appears to be the inclusion of bouncy castle inside the fat jar file, as it includes signing files (.SF, .RSA) that originated there, and now don't correspond with the jar.
Removing those files from the jar will fix this error, however, In my current application I still experience (different) problems with the inclusion of that jar, probably due to bouncy castle - so I can't say for sure if this workaround is sufficient.
Due to the dependency on Bouncy Castle, I recommend that you distribute the send-grid and its dependencies all separately (say as a zip file) as this will avoid the signing problems described in this issue, and also make it easier for people to include the jar in their project without conflicting with their other libraries.
After some further experimentation, I believe that the bouncy castle dependency should be removed entirely, or have its scope changed to "test" because:
- It is only used inside 2 java files - both of which appear to be example code or test code.
- If left in, it conflicts with other code in difficult to predict ways. E.g. I have some JRuby code elsewhere in my app that deals with cryptography, and doesn't even use bouncy castle, and it fails with:
Caused by: java.lang.NoSuchFieldError: qTESLA_I
at org.bouncycastle.operator.DefaultSignatureAlgorithmIdentifierFinder.<clinit>(Unknown Source)
at org.jruby.ext.openssl.impl.PKCS10Request.sign(PKCS10Request.java:139)
at org.jruby.ext.openssl.X509Request.sign(X509Request.java:327)
at org.jruby.ext.openssl.X509Request$INVOKER$i$2$0$sign.call(X509Request$INVOKER$i$2$0$sign.gen)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:396)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:205)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:325)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:121)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:108)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:192)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:354)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:143)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:345)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.Interpreter.INTERPRET_ROOT(Interpreter.java:96)
at org.jruby.ir.interpreter.Interpreter.execute(Interpreter.java:81)
at org.jruby.ir.interpreter.Interpreter.execute(Interpreter.java:30)
at org.jruby.ir.IRTranslator.execute(IRTranslator.java:42)
at org.jruby.Ruby.runInterpreter(Ruby.java:1240)
at org.jruby.Ruby.runInterpreter(Ruby.java:1244)
at org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:118)
... 10 more
If I remove the bouncy castle jar from the classpath, then the problem goes away. 3. The bouncy castle dependency being merged into the fat jar is the cause of the OP error.
Workaround for those Using Maven
For those using Maven, you can filter this out in the dependency using the following snippet in your pom.xml file.
<dependency>
<groupId>com.sendgrid</groupId>
<artifactId>sendgrid-java</artifactId>
<version>4.7.1</version>
<exclusions>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15on</artifactId>
</exclusion>
</exclusions>
</dependency>
Only after doing this, does the sengrid jar work property without conflicting with other libs.
Thanks @shannah for your research and the workaround!
I ran into this same problem. Thanks to @shannah I was able to remove bouncycastle from the jar build and now it works! This really should be fixed!