I tried updating to bouncycastle 1.52 (I was using 1.50) and making my dependencies look as much like the ones in the examples pom.xml as possible, but it just does not work.
It occurred to me that for the purposes of my application the pdf is just going to go straight to the printer and no end user will care if there is an actual electronic signature. So I am just going to draw the signature over the top of the signature fields and call it good. But I am disturbed that it was impossible for me to get visible signatures to work with 2.0 (or any signatures). I would be very happy to help anyone who wants to investigate this. If I had time I would love to make contributions to the PDFBox project because I see how valuable it is and I feel strongly about it. But I don't have time and I need to concern myself with the application I am writing and giving my own users the best experience possible. Thank you so much for your help! On Thu, Jul 2, 2015 at 7:49 AM, Evan Williams <[email protected]> wrote: > But making a standalone jar is not what I am doing. Not at all. > > I have a web application that is deployed by maven. No jars were harmed in > the making of this application. > > And as I said in my email this always always worked perfectly and I never > ever got this error with 1.8.9. I am compliling exactly the same code and > building and deploying exactly the same way as I always did. The ONLY > difference (aside from completely irrelevant updates to code that is not in > this code path) is that I am using 2.0 rather than 1.8.9. And if I take my > code and edit my pom.xml to use 1.8.9 rather than 2.0 it all works again. > > The only thing I am changing is that I use 2.0. If I go back to 1.8.9 it > works again. > > What I am going to do is carefully compare the derived dependencies that > maven comes up with to see if there is some important difference there. Or > at least a clue. > > Thanks. > > On Thu, Jul 2, 2015 at 2:58 AM, Thomas Chojecki <[email protected]> > wrote: > >> Hi all, >> for crypto stuff the bc provider need to be signed (provider signature). >> Making a standalone jar (jar with dependencies) will break the signature of >> the jar. So registering the BC as provider will not work. You can see in >> the exception this message "JCE cannot authenticate the provider BC". >> >> Additionally, switching between 1.8.x and 2.0.x brings different BC >> versions which aren't compatible between each other for signing stuff. You >> can force a BC version but then you maybe would have problems with >> encrypted pdf documents. >> >> And as Andreas already said, don't use the pdfbox-app as the base for an >> application, it is for demo / example purpose only. So the users can just >> check some pdfbox features from the command line. >> >> Best regards >> Thomas >> >> >> Zitat von Andreas Lehmkühler <[email protected]>: >> >> >> Hi, >>> >>> Torgeir Veimo <[email protected]> hat am 2. Juli 2015 um 05:54 >>>> geschrieben: >>>> >>>> >>>> I recently had some unexpected bouncy castle issues and didn't realise >>>> until I read this that the 2.0.0-SNAPSHOT actually includes the bouncy >>>> castle class files! Will the practice be abandoned for release jars? >>>> It will definitely cause deployment issues if this practice is kept >>>> with the final 2.0.0 release. >>>> >>> I guess there is a misunderstanding. Only the pdfbox-app jar contains >>> all those >>> third party dependencies. That jar is meant to be a standalone jar to be >>> used as >>> commandline app. >>> >>> If you are building your own application you should include the jars of >>> the >>> pdfbox subprojects itself, such as >>> >>> fontbox >>> pdfbox >>> >>> and maybe the following as well (if needed) >>> >>> xmpbox >>> preflight >>> >>> >>>> On 2 July 2015 at 05:31, Andreas Lehmkuehler <[email protected]> wrote: >>>> > Hi, >>>> > >>>> > >>>> > Am 01.07.2015 um 20:27 schrieb Evan Williams: >>>> >> >>>> >> I am, as I have said before, taking a working application that used >>>> PDFBox >>>> >> 1.8.9 amd updating it for 2.0. >>>> >> >>>> >> I have fixed everything (with the help of the excellent people on >>>> this >>>> >> list) but one bug persists. >>>> >> >>>> >> I have visual signature code which is an adaptation of the Visible >>>> >> Signature example included in the PDFBox examples. >>>> >> >>>> >> Before it just worked (though there were some issues). >>>> >> >>>> >> But when I went to 2.0 I began to get the infamous 'JCE cannot >>>> >> authenticate >>>> >> the provider BC' exception. >>>> >> >>>> >> *java.io.IOException: error constructing MAC: >>>> java.lang.SecurityException: >>>> >> JCE cannot authenticate the provider BC at >>>> >> >>>> >> >>>> org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi.engineLoad(Unknown >>>> >> Source) at java.security.KeyStore.load(KeyStore.java:1433) at >>>> >> com.zapprx.rxforms.authorizations.KeyRing.<init>(KeyRing.java:62) at >>>> >> com.zapprx.rxforms.KeyRingTest.testKeyRing(KeyRingTest.java:30) at >>>> >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at >>>> >> >>>> >> >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> >> at >>>> >> >>>> >> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >> at java.lang.reflect.Method.invoke(Method.java:483) at >>>> >> >>>> >> >>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) >>>> >> at >>>> >> >>>> >> >>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >>>> >> at >>>> >> >>>> >> >>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) >>>> >> at >>>> >> >>>> >> >>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >>>> >> at >>>> >> >>>> >> >>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) >>>> >> at >>>> >> >>>> >> >>>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) >>>> >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at >>>> >> >>>> >> >>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) >>>> >> at >>>> >> >>>> >> >>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) >>>> >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at >>>> >> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at >>>> >> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at >>>> >> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at >>>> >> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at >>>> >> org.junit.runners.ParentRunner.run(ParentRunner.java:309) at >>>> >> >>>> >> >>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) >>>> >> at >>>> >> >>>> >> >>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) >>>> >> at >>>> >> >>>> >> >>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) >>>> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at >>>> >> >>>> >> >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> >> at >>>> >> >>>> >> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >> at java.lang.reflect.Method.invoke(Method.java:483) at >>>> >> >>>> >> >>>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) >>>> >> at >>>> >> >>>> >> >>>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) >>>> >> at >>>> >> >>>> >> >>>> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) >>>> >> at >>>> >> >>>> >> >>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) >>>> >> at >>>> >> >>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) * >>>> >> The code that causes this is just >>>> >> >>>> >> * Provider provider = new BouncyCastleProvider();* >>>> >> * KeyStore keystore = KeyStore.getInstance("PKCS12", >>>> >> provider);* >>>> >> * char[] pin = pinString.toCharArray();* >>>> >> * keystore.load(ksInputStream, pin);* >>>> >> >>>> >> (presume with me that the pin and the input stream are OK.) >>>> >> >>>> >> There have been absolutely no code changes whatsoever in the code >>>> path in >>>> >> question and the only change to the build (I am building with maven) >>>> is to >>>> >> replace 1.8.9 with 2.0. >>>> >> >>>> >> It is a long shot but maybe this is a FAQ, or maybe someone will say >>>> 'of >>>> >> course, because we changed this in 2.0!' >>>> >> >>>> >> Or maybe not. >>>> >> >>>> >> But if anyone has an idea please clue me in. Stack overflow has a >>>> variety >>>> >> of answers but they all relate to things that have nothing to do >>>> with what >>>> >> I am soing, or do not explain why it used to work pre-2.0 and >>>> doesn't with >>>> >> 2.0. >>>> > >>>> > I'm not a BC expert but we upgraded BC from 1.44 to 1.51. Although the >>>> > numbers may lead to the assumption that this is minor change, it >>>> isn't. >>>> > Those versions aren't binary compatible and obviously there are some >>>> other >>>> > differences. >>>> > >>>> > Sorry, that I can't help you directly, but I guess you should >>>> investigate >>>> > the BC upgrade path. >>>> > >>>> >> Thank you. >>>> >> >>>> > >>>> > BR >>>> > Andreas >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: [email protected] >>>> > For additional commands, e-mail: [email protected] >>>> > >>>> >>>> >>>> >>>> -- >>>> -Tor >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> BR >>> Andreas >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > *Evan Williams* > Sr. Software Engineer > [email protected] > > *www.ZappRx.com <http://www.zapprx.com/>* > > -- *Evan Williams* Sr. Software Engineer [email protected] *www.ZappRx.com <http://www.zapprx.com/>*
