You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Evan Williams <ev...@zapprx.com> on 2015/07/01 20:27:59 UTC
Bouncycastle Provider Suddenly Stopped Working wehn I went to PDFBox 2.0
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.
Thank you.
--
*Evan Williams*
Sr. Software Engineer
evan.williams@zapprx.com
*www.ZappRx.com <http://www.zapprx.com/>*
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to PDFBox 2.0
Posted by John Hewson <jo...@jahewson.com>.
> On 1 Jul 2015, at 23:21, Andreas Lehmkühler <an...@lehmi.de> wrote:
>
> Hi,
>
>> Torgeir Veimo <to...@gmail.com> 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.
Now that we've moved the command line tools to the " tools" jar, there's no real
need for the "app" jar. We could simply bundle dependencies into the "tools" jar.
Actually, I'm not even sure hat bundling dependencies is a good idea, because we
have GPL'd dependencies which aren't bundled - so it's not like we end up with a
single jar anyway.
Seems like we could avoid a lot of confusion is way?
-- John
> 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 <an...@lehmi.de> 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: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>>
>> --
>> -Tor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>
> BR
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Torgeir Veimo <to...@gmail.com>.
Ah, that explains it perfectly, thx!
On 2 July 2015 at 16:21, Andreas Lehmkühler <an...@lehmi.de> wrote:
> Hi,
>
>> Torgeir Veimo <to...@gmail.com> 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 <an...@lehmi.de> 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: users-unsubscribe@pdfbox.apache.org
>> > For additional commands, e-mail: users-help@pdfbox.apache.org
>> >
>>
>>
>>
>> --
>> -Tor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
> BR
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
--
-Tor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Evan Williams <ev...@zapprx.com>.
Thank you! I will check that out.
On Thu, Jul 2, 2015 at 10:12 AM, Lachezar Dobrev <l....@gmail.com> wrote:
> You might want to check if you're not being plagued by transitive
> dependencies woes.
> Use "mvn dependency:tree" to check the dependencies in your project. You
> may be surprised.
>
> 2015-07-02 17:09 GMT+03:00 Evan Williams <ev...@zapprx.com>:
>
> > 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 <ev...@zapprx.com>
> > 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 <in...@rayman2200.de>
> > > 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 <an...@lehmi.de>:
> > >>
> > >>
> > >> Hi,
> > >>>
> > >>> Torgeir Veimo <to...@gmail.com> 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 <an...@lehmi.de>
> > 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: users-unsubscribe@pdfbox.apache.org
> > >>>> > For additional commands, e-mail: users-help@pdfbox.apache.org
> > >>>> >
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> -Tor
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> > >>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> > >>>>
> > >>>>
> > >>> BR
> > >>> Andreas
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> > >>> For additional commands, e-mail: users-help@pdfbox.apache.org
> > >>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> > >> For additional commands, e-mail: users-help@pdfbox.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > *Evan Williams*
> > > Sr. Software Engineer
> > > evan.williams@zapprx.com
> > >
> > > *www.ZappRx.com <http://www.zapprx.com/>*
> > >
> > >
> >
> >
> > --
> > *Evan Williams*
> > Sr. Software Engineer
> > evan.williams@zapprx.com
> >
> > *www.ZappRx.com <http://www.zapprx.com/>*
> >
>
--
*Evan Williams*
Sr. Software Engineer
evan.williams@zapprx.com
*www.ZappRx.com <http://www.zapprx.com/>*
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Lachezar Dobrev <l....@gmail.com>.
You might want to check if you're not being plagued by transitive
dependencies woes.
Use "mvn dependency:tree" to check the dependencies in your project. You
may be surprised.
2015-07-02 17:09 GMT+03:00 Evan Williams <ev...@zapprx.com>:
> 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 <ev...@zapprx.com>
> 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 <in...@rayman2200.de>
> > 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 <an...@lehmi.de>:
> >>
> >>
> >> Hi,
> >>>
> >>> Torgeir Veimo <to...@gmail.com> 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 <an...@lehmi.de>
> 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: users-unsubscribe@pdfbox.apache.org
> >>>> > For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -Tor
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>
> >>>>
> >>> BR
> >>> Andreas
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
> >>
> >
> >
> > --
> > *Evan Williams*
> > Sr. Software Engineer
> > evan.williams@zapprx.com
> >
> > *www.ZappRx.com <http://www.zapprx.com/>*
> >
> >
>
>
> --
> *Evan Williams*
> Sr. Software Engineer
> evan.williams@zapprx.com
>
> *www.ZappRx.com <http://www.zapprx.com/>*
>
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Evan Williams <ev...@zapprx.com>.
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 <ev...@zapprx.com>
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 <in...@rayman2200.de>
> 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 <an...@lehmi.de>:
>>
>>
>> Hi,
>>>
>>> Torgeir Veimo <to...@gmail.com> 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 <an...@lehmi.de> 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: users-unsubscribe@pdfbox.apache.org
>>>> > For additional commands, e-mail: users-help@pdfbox.apache.org
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> -Tor
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>
>>>>
>>> BR
>>> Andreas
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>
>
> --
> *Evan Williams*
> Sr. Software Engineer
> evan.williams@zapprx.com
>
> *www.ZappRx.com <http://www.zapprx.com/>*
>
>
--
*Evan Williams*
Sr. Software Engineer
evan.williams@zapprx.com
*www.ZappRx.com <http://www.zapprx.com/>*
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Evan Williams <ev...@zapprx.com>.
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 <in...@rayman2200.de> 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 <an...@lehmi.de>:
>
>
> Hi,
>>
>> Torgeir Veimo <to...@gmail.com> 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 <an...@lehmi.de> 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: users-unsubscribe@pdfbox.apache.org
>>> > For additional commands, e-mail: users-help@pdfbox.apache.org
>>> >
>>>
>>>
>>>
>>> --
>>> -Tor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>>
>> BR
>> Andreas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
--
*Evan Williams*
Sr. Software Engineer
evan.williams@zapprx.com
*www.ZappRx.com <http://www.zapprx.com/>*
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Thomas Chojecki <in...@rayman2200.de>.
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 <an...@lehmi.de>:
> Hi,
>
>> Torgeir Veimo <to...@gmail.com> 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 <an...@lehmi.de> 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: users-unsubscribe@pdfbox.apache.org
>> > For additional commands, e-mail: users-help@pdfbox.apache.org
>> >
>>
>>
>>
>> --
>> -Tor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>
> BR
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,
> Torgeir Veimo <to...@gmail.com> 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 <an...@lehmi.de> 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: users-unsubscribe@pdfbox.apache.org
> > For additional commands, e-mail: users-help@pdfbox.apache.org
> >
>
>
>
> --
> -Tor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
BR
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Torgeir Veimo <to...@gmail.com>.
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.
On 2 July 2015 at 05:31, Andreas Lehmkuehler <an...@lehmi.de> 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: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
--
-Tor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Bouncycastle Provider Suddenly Stopped Working wehn I went to
PDFBox 2.0
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
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: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org