You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/02/09 19:43:51 UTC
Re: FYI missing mail
Tim Ellison wrote:
> George Harley wrote:
> <snip>
>> The post I want to refer to does not seem to be in the
>> mailing list archive (!!??!)
>
> I don't remember you saying that (and I would have remembered such an
> eloquent and considered post ;-) )
I didn't get it either, and as he George said, it's not in the archive.
If anyone got it, can you let us know here (and once someone says they
got it, everyone else stop telling us - we just need to know if anyone
got it...)
geir
>
> I still have mail that far back in my reader, and it looks like I didn't
> get it either. Maybe it never hit the list.
>
> p.s. +1 to the comment BTW
>
> Regards,
> Tim
>
>> so let me copy the relevant text in-line
>> here as I believe that what it says is important :
>>
>> --- snip from dev-list append of 1st Feb 2006 by
>> george.c.harley@googlemail.com ---
>>
>> Just to clarify your clarification of the question of current Harmony
>> behaviour ...
>>
>> (A) With the current Harmony build it looks like there is *no attempt*
>> to verify the signature of a signed jar file that has been placed on the
>> bootclasspath. I know this because I took a signed BC provider jar (as
>> downloaded from http://www.bouncycastle.org), deliberately tampered with
>> the .SF file in the META-INF folder by removing a few lines, then added
>> the modified jar to the bootclasspath of a simple program that listed
>> the algorithms supported by the BC provider. Everything worked fine.
>>
>> (B) With the current Harmony build it looks like an attempt is made at
>> verifying the signature of a signed jar in the jre/lib/ext directory.
>> The attempt fails because it involves trying to use functionality
>> exported by the jar currently being verified and so opens up a whole
>> problem with cycles.
>> To my mind, (B) is a definite bug that would be fixed by having a
>> default Harmony provider. The result of my little bit of playing with
>> (A) just reinforces the argument that relying on the bootclasspath to
>> load your third party providers is not er ... secure.
>>
>>
>> --- end of snip from dev-list append of 1st Feb 2006 by
>> george.c.harley@googlemail.com ---
>>
>>
>> Best regards,
>> George
>> IBM UK
>>
>>
>> Geir Magnusson Jr wrote:
>>>
>>> Tim Ellison wrote:
>>>> Arghhh!
>>>>
>>>> make it stop
>>>>
>>>>> From below:
>>>> -Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}
>>>>
>>>>
>>>> putting the CLASSPATH onto the bootclasspath. What are you smokin' ?!
>>> That was the patch :)
>>>
>>> All that really is supposed to do is get junit and bcprov there. I'll
>>> move.
>>>
>>> geir
>>>
>>>>
>>>> [ I know you are fixing this stuff, but I needed to vent ]
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: svn commit: r376144 -
>>>> /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>>
>>>> Date: Thu, 09 Feb 2006 01:44:21 -0000
>>>> From: geirm@apache.org
>>>> Reply-To: harmony-dev@incubator.apache.org
>>>> To: harmony-commits@incubator.apache.org
>>>>
>>>> Author: geirm
>>>> Date: Wed Feb 8 17:44:19 2006
>>>> New Revision: 376144
>>>>
>>>> URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
>>>> Log:
>>>> put the bootclasspath stuff back for classlib tests
>>>> because as I'm renaming some tests, it appears that
>>>> when things reordered, tests broke. On a lark, I put
>>>> it back, and things work. Scary.
>>>>
>>>> Will investigate further, but wanted to fix so tests run
>>>>
>>>> Also, changed one of the exclusion lists due to renaming.
>>>>
>>>>
>>>> Modified:
>>>>
>>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>>
>>>>
>>>> Modified:
>>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>>
>>>> URL:
>>>> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
>>>>
>>>> ==============================================================================
>>>>
>>>> ---
>>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>>
>>>> (original)
>>>> +++
>>>> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
>>>>
>>>> Wed Feb 8 17:44:19 2006
>>>> @@ -499,6 +499,8 @@
>>>> <env key="JAVA_HOME" value="${vm.home}"/>
>>>>
>>>> <!-- to pick up junit.jar and bouncycastle.jar -->
>>>> + <jvmarg
>>>> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator}${build.jars.path}/x_net.jar"/>
>>>>
>>>> +
>>>> <jvmarg
>>>> value="-Xbootclasspath/a:${build.path}/tests${path.separator}${env.CLASSPATH}"/>
>>>>
>>>>
>>>> <jvmarg
>>>> value="-Djava.security.properties==${build.lib.path}/security/java.security"/>
>>>>
>>>> @@ -518,7 +520,7 @@
>>>> <exclude
>>>> name="org/apache/harmony/security/test/**"/>
>>>> <!-- Harmony exclude list -->
>>>> - <exclude
>>>> name="java/security/AlgorithmParameterGeneratorTest1.java"/>
>>>> + <exclude
>>>> name="java/security/AlgorithmParameterGenerator1Test.java"/>
>>>> <exclude name="java/security/KSBuilderTest.java"/>
>>>> <exclude
>>>> name="java/security/KeyPairGeneratorTest1.java"/>
>>>> <exclude
>>>> name="java/security/KeyPairGeneratorTest3.java"/>
>>>>
>>>>
>>>>
>>>>
>>
>
Re: FYI missing mail
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Process note :
(George : I don't believe that there's any problem here, but using it as
an example.)
If you ever are in the situation where you will forward a private
exchange to a public list, be sure to ask all participants in the
exchange for permission. People can react in different and surprising
ways to this, so it's always good to take the extra step and get
explicit permission.
gei
George Harley wrote:
> Hi,
>
> Aha ! Mystery solved. I must have screwed up when replying to one of
> Stepan's earlier posts.
>
> Thanks Stepan.
>
> Here is a paste of last week's dialogue then that *I thought* was going
> to the list....
>
> Best regards,
> George
>
> --------------------paste of note from George to Stepan sent on 1st Feb
> at 10:16am GMT------------------------
>
> Hi Stepan,
>
> Thanks for your response. My comments are inlined below.
>
> Best regards,
> George
> IBM UK
>
>
> Stepan Mishura wrote:
>>
>> Hi George,
>>
>> I just suggested a possible way to make a provider 'trusted'.
>>
>> As far as I know the spec. doesn't explicitly define which kind of jar
>> files is trusted. And security implementation only provides API to
>> verify a jar's signature. A decision whether to verify a particular
>> jar or not is taken in jar implementation.
>>
>> We have to work out our approach for jar verification and trusted
>> providers. We have the following variants:
>> - define a special location for trusted jar file, for example,
>> bootclasspath, lib/ext directory and put BC provider here
>
> OK, I appreciate that the above are examples but allow me to just add my
> shiny two pence sterling. Specifying that third party provider jars need
> to go on the bootclasspath means additional work for the user. They are
> either going to have to add in the necessary -Xbootclasspath option to
> every launch (tedious) or else drop the jar into jre/lib/boot and update
> the bootclasspath.properties file with information on the extra entry
> (tedious and potentially dangerous as this is one file we really don't
> want to be edited too often). I personally find neither appealing.
>
> I also find it somewhat misleading to be using the bootclasspath for
> loading third party libraries which are not essential for the
> bootstrapping of the JRE. These libraries are extending the JRE. That's
> why I think that using the extensions loader is the better option from
> your examples. It also has the practical benefit of alleviating user
> burden if they can just drop a third party provider jar into jre/lib/ext
> and forget about any extra command line options.
>
>> - develop Harmony provider (and exclude necessity of having a
>> 'trusted' location)
>
> Yes, absolutely ! We need a "default" Harmony provider at position #1 in
> the preferred provider search sequence that has sufficient functionality
> to handle the verification of signed jars. This would rid us of this
> cyclic problem we currently have with the BC jar.
>
>> - use any unsigned jar form open source
>
> Providers like Bouncy Castle and Cryptix etc typically deliver their
> classes inside signed jars. Don't you think it would seem a bit strange
> asking Harmony users to "unsign" these jars before actually using in
> Harmony ? For one thing, it is again more work for the user (I know I
> keep harping on about the poor old users, but I kind of have a soft spot
> for them) and introduces a point of potential failure into the platform
> configuration as people may inadvertently screw up the "unsigning".
>
>> - let's user to decide whether a provider is trusted or not and where
>> to place it
>
> It would be nice if Harmony could help inform them whether or not a
> signed provider jar is verifiably trustworthy.
>
>> - others ….
>>
>> My suggestion in harmony-dev mailing list coincided with the current
>> Harmony build behavior: when a signed provider jar (e.g. BC provider)
>> is placed to bootclasspath to run security2 tests then signature is
>> not verified. So I may call it a 'trusted' provider. And according to
>> your experiments if I'll move it to lib/ext then it will need to pass
>> jar verification. So I may call it 'untrusted' provider. However I
>> don't know whether such behavior was especially designed or not.
>>
>
> As mentioned above, I think that a default Harmony provider (something
> like security.provider.1=org.apache.harmony.provider.Harmony in the
> java.security file) that could verify third party jars without having to
> rely on functionality from third party jars is the way forward.
> Certainly better than using the bootclasspath as a salve for all our
> problems.
>
>
> Thanks,
> Stepan.
>
>
>
> On 1/31/06, *George Harley* <george.c.harley@googlemail.com
> <ma...@googlemail.com>> wrote: Hi Stepan,
>
> Not sure that I understand. Are you saying that taking a signed provider
> jar (e.g. bcprov-jdk14-131.jar) and adding it to the bootclasspath makes
> it a "trusted" provider ?
>
> Best regards,
> George
> IBM UK
>
> Stepan Mishura wrote:
>>
>> >
>> >Certainly the Bouncy Castle jar contains an implementation of the SHA
>> >algorithm. Assuming that you have an uncorrupted BC provider jar in
>> ><HARMONY_JRE>/lib/ext, does this failure get fixed by "unsigning" the BC
>> >jar ?
>> >
>>
>> Well, there is a cyclic dependency here: to verify a signed jar we
>> need already verified provider that has all required algorithms for
>> jar verification. To avoid this we can define a 'trusted' provider,
>> for example, currently a signed provider's jar is not verified if it
>> was added to the bootclasspath. Or we can create an unsigned
>> provider's jar intended for jar verification.
>>
>> BTW, all tests from security2 passed because ant script used to run
>> tests explicitly adds the required provider to the bootclasspath.
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>
>
> ----------------------------------------------------------------------------------------------------------------
>
> --------------------end of paste of note from George to Stepan sent on
> 1st Feb at 10:16am GMT-------------------
>
>
>
>
> Stepan Mishura wrote:
>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>>
>>> Tim Ellison wrote:
>>>
>>>> George Harley wrote:
>>>> <snip>
>>>>
>>>>> The post I want to refer to does not seem to be in the
>>>>> mailing list archive (!!??!)
>>>>>
>>>> I don't remember you saying that (and I would have remembered such an
>>>> eloquent and considered post ;-) )
>>>>
>>> I didn't get it either, and as he George said, it's not in the archive.
>>>
>>> If anyone got it, can you let us know here (and once someone says they
>>> got it, everyone else stop telling us - we just need to know if anyone
>>> got it...)
>>>
>>
>>
>>
>> I got it. I thought it was done intentionally: George sent it directly
>> to me
>> only ... so it is not in the list.
>>
>> Returning back to the 'missing post'. I agreed with suggestion but
>> currently
>> we don't have Harmony provider so we should define how we locate 'trusted
>> provides' to be secure.
>>
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>> geir
>>
>>>> I still have mail that far back in my reader, and it looks like I
>>>> didn't
>>>> get it either. Maybe it never hit the list.
>>>>
>>>> p.s. +1 to the comment BTW
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>
>>>>> so let me copy the relevant text in-line
>>>>> here as I believe that what it says is important :
>>>>>
>>>>> --- snip from dev-list append of 1st Feb 2006 by
>>>>> george.c.harley@googlemail.com ---
>>>>>
>>>>> Just to clarify your clarification of the question of current Harmony
>>>>> behaviour ...
>>>>>
>>>>> (A) With the current Harmony build it looks like there is *no attempt*
>>>>> to verify the signature of a signed jar file that has been placed on
>>>>>
>>> the
>>>
>>>>> bootclasspath. I know this because I took a signed BC provider jar (as
>>>>> downloaded from http://www.bouncycastle.org), deliberately tampered
>>>>>
>>> with
>>>
>>>>> the .SF file in the META-INF folder by removing a few lines, then
>>>>> added
>>>>> the modified jar to the bootclasspath of a simple program that listed
>>>>> the algorithms supported by the BC provider. Everything worked fine.
>>>>>
>>>>> (B) With the current Harmony build it looks like an attempt is made at
>>>>> verifying the signature of a signed jar in the jre/lib/ext directory.
>>>>> The attempt fails because it involves trying to use functionality
>>>>> exported by the jar currently being verified and so opens up a whole
>>>>> problem with cycles.
>>>>> To my mind, (B) is a definite bug that would be fixed by having a
>>>>> default Harmony provider. The result of my little bit of playing with
>>>>> (A) just reinforces the argument that relying on the bootclasspath to
>>>>> load your third party providers is not er ... secure.
>>>>>
>>>>>
>>>>> --- end of snip from dev-list append of 1st Feb 2006 by
>>>>> george.c.harley@googlemail.com ---
>>>>>
>>>>>
>>>>> Best regards,
>>>>> George
>>>>> IBM UK
>>>>>
>>>>>
>>>>> Geir Magnusson Jr wrote:
>>>>>
>>>>>> Tim Ellison wrote:
>>>>>>
>>>>>>> Arghhh!
>>>>>>>
>>>>>>> make it stop
>>>>>>>
>>>>>>>
>>>>>>>> From below:
>>>>>>>>
>>>>>>> -Xbootclasspath/a:${build.path}/tests${path.separator}${
>>>>>>>
>>> env.CLASSPATH}
>>>
>>>>>>> putting the CLASSPATH onto the bootclasspath. What are you smokin'
>>>>>>>
>>> ?!
>>>
>>>>>> That was the patch :)
>>>>>>
>>>>>> All that really is supposed to do is get junit and bcprov there.
>>>>>> I'll
>>>>>> move.
>>>>>>
>>>>>> geir
>>>>>>
>>>>>>
>>>>>>> [ I know you are fixing this stuff, but I needed to vent ]
>>>>>>>
>>>>>>>
>>>>>>> -------- Original Message --------
>>>>>>> Subject: svn commit: r376144 -
>>>>>>>
>>>>>>>
> <snip>
>
>
Re: FYI missing mail
Posted by George Harley <ge...@googlemail.com>.
Hi,
Aha ! Mystery solved. I must have screwed up when replying to one of
Stepan's earlier posts.
Thanks Stepan.
Here is a paste of last week's dialogue then that *I thought* was going
to the list....
Best regards,
George
--------------------paste of note from George to Stepan sent on 1st Feb
at 10:16am GMT------------------------
Hi Stepan,
Thanks for your response. My comments are inlined below.
Best regards,
George
IBM UK
Stepan Mishura wrote:
>
> Hi George,
>
> I just suggested a possible way to make a provider 'trusted'.
>
> As far as I know the spec. doesn't explicitly define which kind of jar
> files is trusted. And security implementation only provides API to
> verify a jar's signature. A decision whether to verify a particular
> jar or not is taken in jar implementation.
>
> We have to work out our approach for jar verification and trusted
> providers. We have the following variants:
> - define a special location for trusted jar file, for example,
> bootclasspath, lib/ext directory and put BC provider here
OK, I appreciate that the above are examples but allow me to just add my
shiny two pence sterling. Specifying that third party provider jars need
to go on the bootclasspath means additional work for the user. They are
either going to have to add in the necessary -Xbootclasspath option to
every launch (tedious) or else drop the jar into jre/lib/boot and update
the bootclasspath.properties file with information on the extra entry
(tedious and potentially dangerous as this is one file we really don't
want to be edited too often). I personally find neither appealing.
I also find it somewhat misleading to be using the bootclasspath for
loading third party libraries which are not essential for the
bootstrapping of the JRE. These libraries are extending the JRE. That's
why I think that using the extensions loader is the better option from
your examples. It also has the practical benefit of alleviating user
burden if they can just drop a third party provider jar into jre/lib/ext
and forget about any extra command line options.
> - develop Harmony provider (and exclude necessity of having a
> 'trusted' location)
Yes, absolutely ! We need a "default" Harmony provider at position #1 in
the preferred provider search sequence that has sufficient functionality
to handle the verification of signed jars. This would rid us of this
cyclic problem we currently have with the BC jar.
> - use any unsigned jar form open source
Providers like Bouncy Castle and Cryptix etc typically deliver their
classes inside signed jars. Don't you think it would seem a bit strange
asking Harmony users to "unsign" these jars before actually using in
Harmony ? For one thing, it is again more work for the user (I know I
keep harping on about the poor old users, but I kind of have a soft spot
for them) and introduces a point of potential failure into the platform
configuration as people may inadvertently screw up the "unsigning".
> - let's user to decide whether a provider is trusted or not and where
> to place it
It would be nice if Harmony could help inform them whether or not a
signed provider jar is verifiably trustworthy.
> - others ….
>
> My suggestion in harmony-dev mailing list coincided with the current
> Harmony build behavior: when a signed provider jar (e.g. BC provider)
> is placed to bootclasspath to run security2 tests then signature is
> not verified. So I may call it a 'trusted' provider. And according to
> your experiments if I'll move it to lib/ext then it will need to pass
> jar verification. So I may call it 'untrusted' provider. However I
> don't know whether such behavior was especially designed or not.
>
As mentioned above, I think that a default Harmony provider (something
like security.provider.1=org.apache.harmony.provider.Harmony in the
java.security file) that could verify third party jars without having to
rely on functionality from third party jars is the way forward.
Certainly better than using the bootclasspath as a salve for all our
problems.
Thanks,
Stepan.
On 1/31/06, *George Harley* <george.c.harley@googlemail.com
<ma...@googlemail.com>> wrote: Hi Stepan,
Not sure that I understand. Are you saying that taking a signed provider
jar (e.g. bcprov-jdk14-131.jar) and adding it to the bootclasspath makes
it a "trusted" provider ?
Best regards,
George
IBM UK
Stepan Mishura wrote:
>
> >
> >Certainly the Bouncy Castle jar contains an implementation of the SHA
> >algorithm. Assuming that you have an uncorrupted BC provider jar in
> ><HARMONY_JRE>/lib/ext, does this failure get fixed by "unsigning" the BC
> >jar ?
> >
>
> Well, there is a cyclic dependency here: to verify a signed jar we
> need already verified provider that has all required algorithms for
> jar verification. To avoid this we can define a 'trusted' provider,
> for example, currently a signed provider's jar is not verified if it
> was added to the bootclasspath. Or we can create an unsigned
> provider's jar intended for jar verification.
>
> BTW, all tests from security2 passed because ant script used to run
> tests explicitly adds the required provider to the bootclasspath.
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
----------------------------------------------------------------------------------------------------------------
--------------------end of paste of note from George to Stepan sent on
1st Feb at 10:16am GMT-------------------
Stepan Mishura wrote:
> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>>
>> Tim Ellison wrote:
>>
>>> George Harley wrote:
>>> <snip>
>>>
>>>> The post I want to refer to does not seem to be in the
>>>> mailing list archive (!!??!)
>>>>
>>> I don't remember you saying that (and I would have remembered such an
>>> eloquent and considered post ;-) )
>>>
>> I didn't get it either, and as he George said, it's not in the archive.
>>
>> If anyone got it, can you let us know here (and once someone says they
>> got it, everyone else stop telling us - we just need to know if anyone
>> got it...)
>>
>
>
>
> I got it. I thought it was done intentionally: George sent it directly to me
> only ... so it is not in the list.
>
> Returning back to the 'missing post'. I agreed with suggestion but currently
> we don't have Harmony provider so we should define how we locate 'trusted
> provides' to be secure.
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> geir
>
>>> I still have mail that far back in my reader, and it looks like I didn't
>>> get it either. Maybe it never hit the list.
>>>
>>> p.s. +1 to the comment BTW
>>>
>>> Regards,
>>> Tim
>>>
>>>
>>>> so let me copy the relevant text in-line
>>>> here as I believe that what it says is important :
>>>>
>>>> --- snip from dev-list append of 1st Feb 2006 by
>>>> george.c.harley@googlemail.com ---
>>>>
>>>> Just to clarify your clarification of the question of current Harmony
>>>> behaviour ...
>>>>
>>>> (A) With the current Harmony build it looks like there is *no attempt*
>>>> to verify the signature of a signed jar file that has been placed on
>>>>
>> the
>>
>>>> bootclasspath. I know this because I took a signed BC provider jar (as
>>>> downloaded from http://www.bouncycastle.org), deliberately tampered
>>>>
>> with
>>
>>>> the .SF file in the META-INF folder by removing a few lines, then added
>>>> the modified jar to the bootclasspath of a simple program that listed
>>>> the algorithms supported by the BC provider. Everything worked fine.
>>>>
>>>> (B) With the current Harmony build it looks like an attempt is made at
>>>> verifying the signature of a signed jar in the jre/lib/ext directory.
>>>> The attempt fails because it involves trying to use functionality
>>>> exported by the jar currently being verified and so opens up a whole
>>>> problem with cycles.
>>>> To my mind, (B) is a definite bug that would be fixed by having a
>>>> default Harmony provider. The result of my little bit of playing with
>>>> (A) just reinforces the argument that relying on the bootclasspath to
>>>> load your third party providers is not er ... secure.
>>>>
>>>>
>>>> --- end of snip from dev-list append of 1st Feb 2006 by
>>>> george.c.harley@googlemail.com ---
>>>>
>>>>
>>>> Best regards,
>>>> George
>>>> IBM UK
>>>>
>>>>
>>>> Geir Magnusson Jr wrote:
>>>>
>>>>> Tim Ellison wrote:
>>>>>
>>>>>> Arghhh!
>>>>>>
>>>>>> make it stop
>>>>>>
>>>>>>
>>>>>>> From below:
>>>>>>>
>>>>>> -Xbootclasspath/a:${build.path}/tests${path.separator}${
>>>>>>
>> env.CLASSPATH}
>>
>>>>>> putting the CLASSPATH onto the bootclasspath. What are you smokin'
>>>>>>
>> ?!
>>
>>>>> That was the patch :)
>>>>>
>>>>> All that really is supposed to do is get junit and bcprov there. I'll
>>>>> move.
>>>>>
>>>>> geir
>>>>>
>>>>>
>>>>>> [ I know you are fixing this stuff, but I needed to vent ]
>>>>>>
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Subject: svn commit: r376144 -
>>>>>>
>>>>>>
<snip>
Re: verifying signed jars
Posted by Davanum Srinivas <da...@gmail.com>.
Folks,
FYI, we are going take some code from BC in juice project. Check [1]
for more info.
thanks,
dims
[1] http://mail-archives.apache.org/mod_mbox/xml-juice-dev/200601.mbox/%3C43CE5A15.6030202@t-online.de%3E
On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Heh. Everything we will do is legal :)
>
> The point is - would taking some source from BC be the smart thing to do
> - would it be complete, and what kind of maintenance burden would this
> be going forward? Would some kind of re-packaged artifact from the BC
> project itself be better?
>
> Do we need source? Could we have a step where we re-package BC code in
> a form more suited for our purposes?
>
> geir
>
> Mikhail Loenko wrote:
> > We can if it is legal
> >
> > Thanks,
> > Mikhail
> >
> > On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> So I'll ask the obvious - can we borrow some of this from BC?
> >>
> >> Stepan Mishura wrote:
> >>> We should have at least to verify BC provider:
> >>> 1) Message digest algorithm: SHA-1
> >>> 2) Signature algorithm: SHA1withDSA
> >>>
> >>> Other jars may require additional algorithms, for example, SHA1withRSA. We
> >>> can verify BC provider first and use it for further jar verifications.
> >>>
> >>> Thanks,
> >>> Stepan Mishura
> >>> Intel Middleware Products Division
> >>>
> >>>
> >>>
> >>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
> >>>> Hi Tim,
> >>>>
> >>>> In order to verify the signature of those signed provider jars I believe
> >>>> that you would also need trusted implementations of :
> >>>>
> >>>> * SHA-1 and MD5 digest algorithms
> >>>> * DSA and RSA signature algorithms
> >>>>
> >>>>
> >>>> Best regards,
> >>>> George
> >>>> IBM UK
> >>>>
> >>>>
> >>>> Tim Ellison wrote:
> >>>>> Stepan Mishura wrote:
> >>>>> <snip>
> >>>>>
> >>>>>> Returning back to the 'missing post'. I agreed with suggestion but
> >>>> currently
> >>>>>> we don't have Harmony provider so we should define how we locate
> >>>> 'trusted
> >>>>>> provides' to be secure.
> >>>>>>
> >>>>> We just need a trusted SHA1PRNG, right? then we can open signed
> >>>>> providers' jars and get any others.
> >>>>>
> >>>>> Regards,
> >>>>> Tim
> >>>>>
> >>>>>
> >>>
> >>> --
> >>>
> >
> >
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: verifying signed jars
Posted by Mikhail Loenko <ml...@gmail.com>.
Well, we can start with binaries and if we strike a snag will see
Thanks,
Mikhail
On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
> My comment was directed towards:
>
> Mikhail Loenko wrote: "The sources would be good - we would be able to
> fix bugs quickly and replace parts of implementation for example where
> our code is faster."
>
> i.e. why not fix bugs and make it go faster for everyone -- no need to fork.
>
> Regards,
> Tim
>
> Mikhail Loenko wrote:
> > How will it solve our problem with verifying signed jars?
> >
> > Thanks,
> > Mikhail
> >
> > On 2/13/06, Richard Liang <ri...@gmail.com> wrote:
> >> That's a good idea :-)
> >>
> >> Richard Liang
> >> China Software Development Lab, IBM
> >>
> >>
> >>
> >> Tim Ellison wrote:
> >>> Why not contribute directly to BouncyCastle?
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>> Mikhail Loenko wrote:
> >>>
> >>>> The sources would be good - we would be able to fix bugs quickly and replace
> >>>> parts of implementation for example where our code is faster.
> >>>>
> >>>> Thanks,
> >>>> Mikhail
> >>>>
> >>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>
> >>>>> Heh. Everything we will do is legal :)
> >>>>>
> >>>>> The point is - would taking some source from BC be the smart thing to do
> >>>>> - would it be complete, and what kind of maintenance burden would this
> >>>>> be going forward? Would some kind of re-packaged artifact from the BC
> >>>>> project itself be better?
> >>>>>
> >>>>> Do we need source? Could we have a step where we re-package BC code in
> >>>>> a form more suited for our purposes?
> >>>>>
> >>>>> geir
> >>>>>
> >>>>> Mikhail Loenko wrote:
> >>>>>
> >>>>>> We can if it is legal
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Mikhail
> >>>>>>
> >>>>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>>>
> >>>>>>> So I'll ask the obvious - can we borrow some of this from BC?
> >>>>>>>
> >>>>>>> Stepan Mishura wrote:
> >>>>>>>
> >>>>>>>> We should have at least to verify BC provider:
> >>>>>>>> 1) Message digest algorithm: SHA-1
> >>>>>>>> 2) Signature algorithm: SHA1withDSA
> >>>>>>>>
> >>>>>>>> Other jars may require additional algorithms, for example, SHA1withRSA. We
> >>>>>>>> can verify BC provider first and use it for further jar verifications.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Stepan Mishura
> >>>>>>>> Intel Middleware Products Division
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Tim,
> >>>>>>>>>
> >>>>>>>>> In order to verify the signature of those signed provider jars I believe
> >>>>>>>>> that you would also need trusted implementations of :
> >>>>>>>>>
> >>>>>>>>> * SHA-1 and MD5 digest algorithms
> >>>>>>>>> * DSA and RSA signature algorithms
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> George
> >>>>>>>>> IBM UK
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Tim Ellison wrote:
> >>>>>>>>>
> >>>>>>>>>> Stepan Mishura wrote:
> >>>>>>>>>> <snip>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Returning back to the 'missing post'. I agreed with suggestion but
> >>>>>>>>>>>
> >>>>>>>>> currently
> >>>>>>>>>
> >>>>>>>>>>> we don't have Harmony provider so we should define how we locate
> >>>>>>>>>>>
> >>>>>>>>> 'trusted
> >>>>>>>>>
> >>>>>>>>>>> provides' to be secure.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> We just need a trusted SHA1PRNG, right? then we can open signed
> >>>>>>>>>> providers' jars and get any others.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>> Tim
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>>
> >>>
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: verifying signed jars
Posted by Richard Liang <ri...@gmail.com>.
Hello Mikhail Loenko,
:-) I'm just wondering whether it's possible to change/improve
BouncyCastle to meet our requirement.
Richard Liang
China Software Development Lab, IBM
Mikhail Loenko wrote:
> How will it solve our problem with verifying signed jars?
>
> Thanks,
> Mikhail
>
> On 2/13/06, Richard Liang <ri...@gmail.com> wrote:
>
>> That's a good idea :-)
>>
>> Richard Liang
>> China Software Development Lab, IBM
>>
>>
>>
>> Tim Ellison wrote:
>>
>>> Why not contribute directly to BouncyCastle?
>>>
>>> Regards,
>>> Tim
>>>
>>> Mikhail Loenko wrote:
>>>
>>>
>>>> The sources would be good - we would be able to fix bugs quickly and replace
>>>> parts of implementation for example where our code is faster.
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>
>>>>
>>>>> Heh. Everything we will do is legal :)
>>>>>
>>>>> The point is - would taking some source from BC be the smart thing to do
>>>>> - would it be complete, and what kind of maintenance burden would this
>>>>> be going forward? Would some kind of re-packaged artifact from the BC
>>>>> project itself be better?
>>>>>
>>>>> Do we need source? Could we have a step where we re-package BC code in
>>>>> a form more suited for our purposes?
>>>>>
>>>>> geir
>>>>>
>>>>> Mikhail Loenko wrote:
>>>>>
>>>>>
>>>>>> We can if it is legal
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail
>>>>>>
>>>>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>
>>>>>>
>>>>>>> So I'll ask the obvious - can we borrow some of this from BC?
>>>>>>>
>>>>>>> Stepan Mishura wrote:
>>>>>>>
>>>>>>>
>>>>>>>> We should have at least to verify BC provider:
>>>>>>>> 1) Message digest algorithm: SHA-1
>>>>>>>> 2) Signature algorithm: SHA1withDSA
>>>>>>>>
>>>>>>>> Other jars may require additional algorithms, for example, SHA1withRSA. We
>>>>>>>> can verify BC provider first and use it for further jar verifications.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Stepan Mishura
>>>>>>>> Intel Middleware Products Division
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Tim,
>>>>>>>>>
>>>>>>>>> In order to verify the signature of those signed provider jars I believe
>>>>>>>>> that you would also need trusted implementations of :
>>>>>>>>>
>>>>>>>>> * SHA-1 and MD5 digest algorithms
>>>>>>>>> * DSA and RSA signature algorithms
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> George
>>>>>>>>> IBM UK
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tim Ellison wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Stepan Mishura wrote:
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Returning back to the 'missing post'. I agreed with suggestion but
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> currently
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> we don't have Harmony provider so we should define how we locate
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> 'trusted
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> provides' to be secure.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> We just need a trusted SHA1PRNG, right? then we can open signed
>>>>>>>>>> providers' jars and get any others.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>
>
>
Re: verifying signed jars
Posted by Tim Ellison <t....@gmail.com>.
My comment was directed towards:
Mikhail Loenko wrote: "The sources would be good - we would be able to
fix bugs quickly and replace parts of implementation for example where
our code is faster."
i.e. why not fix bugs and make it go faster for everyone -- no need to fork.
Regards,
Tim
Mikhail Loenko wrote:
> How will it solve our problem with verifying signed jars?
>
> Thanks,
> Mikhail
>
> On 2/13/06, Richard Liang <ri...@gmail.com> wrote:
>> That's a good idea :-)
>>
>> Richard Liang
>> China Software Development Lab, IBM
>>
>>
>>
>> Tim Ellison wrote:
>>> Why not contribute directly to BouncyCastle?
>>>
>>> Regards,
>>> Tim
>>>
>>> Mikhail Loenko wrote:
>>>
>>>> The sources would be good - we would be able to fix bugs quickly and replace
>>>> parts of implementation for example where our code is faster.
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>
>>>>> Heh. Everything we will do is legal :)
>>>>>
>>>>> The point is - would taking some source from BC be the smart thing to do
>>>>> - would it be complete, and what kind of maintenance burden would this
>>>>> be going forward? Would some kind of re-packaged artifact from the BC
>>>>> project itself be better?
>>>>>
>>>>> Do we need source? Could we have a step where we re-package BC code in
>>>>> a form more suited for our purposes?
>>>>>
>>>>> geir
>>>>>
>>>>> Mikhail Loenko wrote:
>>>>>
>>>>>> We can if it is legal
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail
>>>>>>
>>>>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>>>
>>>>>>> So I'll ask the obvious - can we borrow some of this from BC?
>>>>>>>
>>>>>>> Stepan Mishura wrote:
>>>>>>>
>>>>>>>> We should have at least to verify BC provider:
>>>>>>>> 1) Message digest algorithm: SHA-1
>>>>>>>> 2) Signature algorithm: SHA1withDSA
>>>>>>>>
>>>>>>>> Other jars may require additional algorithms, for example, SHA1withRSA. We
>>>>>>>> can verify BC provider first and use it for further jar verifications.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Stepan Mishura
>>>>>>>> Intel Middleware Products Division
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Tim,
>>>>>>>>>
>>>>>>>>> In order to verify the signature of those signed provider jars I believe
>>>>>>>>> that you would also need trusted implementations of :
>>>>>>>>>
>>>>>>>>> * SHA-1 and MD5 digest algorithms
>>>>>>>>> * DSA and RSA signature algorithms
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> George
>>>>>>>>> IBM UK
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tim Ellison wrote:
>>>>>>>>>
>>>>>>>>>> Stepan Mishura wrote:
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Returning back to the 'missing post'. I agreed with suggestion but
>>>>>>>>>>>
>>>>>>>>> currently
>>>>>>>>>
>>>>>>>>>>> we don't have Harmony provider so we should define how we locate
>>>>>>>>>>>
>>>>>>>>> 'trusted
>>>>>>>>>
>>>>>>>>>>> provides' to be secure.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> We just need a trusted SHA1PRNG, right? then we can open signed
>>>>>>>>>> providers' jars and get any others.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: verifying signed jars
Posted by Mikhail Loenko <ml...@gmail.com>.
How will it solve our problem with verifying signed jars?
Thanks,
Mikhail
On 2/13/06, Richard Liang <ri...@gmail.com> wrote:
> That's a good idea :-)
>
> Richard Liang
> China Software Development Lab, IBM
>
>
>
> Tim Ellison wrote:
> > Why not contribute directly to BouncyCastle?
> >
> > Regards,
> > Tim
> >
> > Mikhail Loenko wrote:
> >
> >> The sources would be good - we would be able to fix bugs quickly and replace
> >> parts of implementation for example where our code is faster.
> >>
> >> Thanks,
> >> Mikhail
> >>
> >> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>
> >>> Heh. Everything we will do is legal :)
> >>>
> >>> The point is - would taking some source from BC be the smart thing to do
> >>> - would it be complete, and what kind of maintenance burden would this
> >>> be going forward? Would some kind of re-packaged artifact from the BC
> >>> project itself be better?
> >>>
> >>> Do we need source? Could we have a step where we re-package BC code in
> >>> a form more suited for our purposes?
> >>>
> >>> geir
> >>>
> >>> Mikhail Loenko wrote:
> >>>
> >>>> We can if it is legal
> >>>>
> >>>> Thanks,
> >>>> Mikhail
> >>>>
> >>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>>>
> >>>>> So I'll ask the obvious - can we borrow some of this from BC?
> >>>>>
> >>>>> Stepan Mishura wrote:
> >>>>>
> >>>>>> We should have at least to verify BC provider:
> >>>>>> 1) Message digest algorithm: SHA-1
> >>>>>> 2) Signature algorithm: SHA1withDSA
> >>>>>>
> >>>>>> Other jars may require additional algorithms, for example, SHA1withRSA. We
> >>>>>> can verify BC provider first and use it for further jar verifications.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Stepan Mishura
> >>>>>> Intel Middleware Products Division
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
> >>>>>>
> >>>>>>> Hi Tim,
> >>>>>>>
> >>>>>>> In order to verify the signature of those signed provider jars I believe
> >>>>>>> that you would also need trusted implementations of :
> >>>>>>>
> >>>>>>> * SHA-1 and MD5 digest algorithms
> >>>>>>> * DSA and RSA signature algorithms
> >>>>>>>
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> George
> >>>>>>> IBM UK
> >>>>>>>
> >>>>>>>
> >>>>>>> Tim Ellison wrote:
> >>>>>>>
> >>>>>>>> Stepan Mishura wrote:
> >>>>>>>> <snip>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Returning back to the 'missing post'. I agreed with suggestion but
> >>>>>>>>>
> >>>>>>> currently
> >>>>>>>
> >>>>>>>>> we don't have Harmony provider so we should define how we locate
> >>>>>>>>>
> >>>>>>> 'trusted
> >>>>>>>
> >>>>>>>>> provides' to be secure.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> We just need a trusted SHA1PRNG, right? then we can open signed
> >>>>>>>> providers' jars and get any others.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Tim
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>> --
> >>>>>>
> >>>>>>
> >
> >
>
>
Re: verifying signed jars
Posted by Richard Liang <ri...@gmail.com>.
That's a good idea :-)
Richard Liang
China Software Development Lab, IBM
Tim Ellison wrote:
> Why not contribute directly to BouncyCastle?
>
> Regards,
> Tim
>
> Mikhail Loenko wrote:
>
>> The sources would be good - we would be able to fix bugs quickly and replace
>> parts of implementation for example where our code is faster.
>>
>> Thanks,
>> Mikhail
>>
>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>> Heh. Everything we will do is legal :)
>>>
>>> The point is - would taking some source from BC be the smart thing to do
>>> - would it be complete, and what kind of maintenance burden would this
>>> be going forward? Would some kind of re-packaged artifact from the BC
>>> project itself be better?
>>>
>>> Do we need source? Could we have a step where we re-package BC code in
>>> a form more suited for our purposes?
>>>
>>> geir
>>>
>>> Mikhail Loenko wrote:
>>>
>>>> We can if it is legal
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>>
>>>>> So I'll ask the obvious - can we borrow some of this from BC?
>>>>>
>>>>> Stepan Mishura wrote:
>>>>>
>>>>>> We should have at least to verify BC provider:
>>>>>> 1) Message digest algorithm: SHA-1
>>>>>> 2) Signature algorithm: SHA1withDSA
>>>>>>
>>>>>> Other jars may require additional algorithms, for example, SHA1withRSA. We
>>>>>> can verify BC provider first and use it for further jar verifications.
>>>>>>
>>>>>> Thanks,
>>>>>> Stepan Mishura
>>>>>> Intel Middleware Products Division
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>>>>>>
>>>>>>> Hi Tim,
>>>>>>>
>>>>>>> In order to verify the signature of those signed provider jars I believe
>>>>>>> that you would also need trusted implementations of :
>>>>>>>
>>>>>>> * SHA-1 and MD5 digest algorithms
>>>>>>> * DSA and RSA signature algorithms
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> George
>>>>>>> IBM UK
>>>>>>>
>>>>>>>
>>>>>>> Tim Ellison wrote:
>>>>>>>
>>>>>>>> Stepan Mishura wrote:
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Returning back to the 'missing post'. I agreed with suggestion but
>>>>>>>>>
>>>>>>> currently
>>>>>>>
>>>>>>>>> we don't have Harmony provider so we should define how we locate
>>>>>>>>>
>>>>>>> 'trusted
>>>>>>>
>>>>>>>>> provides' to be secure.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> We just need a trusted SHA1PRNG, right? then we can open signed
>>>>>>>> providers' jars and get any others.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>
>
Re: verifying signed jars
Posted by Tim Ellison <t....@gmail.com>.
Why not contribute directly to BouncyCastle?
Regards,
Tim
Mikhail Loenko wrote:
> The sources would be good - we would be able to fix bugs quickly and replace
> parts of implementation for example where our code is faster.
>
> Thanks,
> Mikhail
>
> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Heh. Everything we will do is legal :)
>>
>> The point is - would taking some source from BC be the smart thing to do
>> - would it be complete, and what kind of maintenance burden would this
>> be going forward? Would some kind of re-packaged artifact from the BC
>> project itself be better?
>>
>> Do we need source? Could we have a step where we re-package BC code in
>> a form more suited for our purposes?
>>
>> geir
>>
>> Mikhail Loenko wrote:
>>> We can if it is legal
>>>
>>> Thanks,
>>> Mikhail
>>>
>>> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>>> So I'll ask the obvious - can we borrow some of this from BC?
>>>>
>>>> Stepan Mishura wrote:
>>>>> We should have at least to verify BC provider:
>>>>> 1) Message digest algorithm: SHA-1
>>>>> 2) Signature algorithm: SHA1withDSA
>>>>>
>>>>> Other jars may require additional algorithms, for example, SHA1withRSA. We
>>>>> can verify BC provider first and use it for further jar verifications.
>>>>>
>>>>> Thanks,
>>>>> Stepan Mishura
>>>>> Intel Middleware Products Division
>>>>>
>>>>>
>>>>>
>>>>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>>>>>> Hi Tim,
>>>>>>
>>>>>> In order to verify the signature of those signed provider jars I believe
>>>>>> that you would also need trusted implementations of :
>>>>>>
>>>>>> * SHA-1 and MD5 digest algorithms
>>>>>> * DSA and RSA signature algorithms
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> George
>>>>>> IBM UK
>>>>>>
>>>>>>
>>>>>> Tim Ellison wrote:
>>>>>>> Stepan Mishura wrote:
>>>>>>> <snip>
>>>>>>>
>>>>>>>> Returning back to the 'missing post'. I agreed with suggestion but
>>>>>> currently
>>>>>>>> we don't have Harmony provider so we should define how we locate
>>>>>> 'trusted
>>>>>>>> provides' to be secure.
>>>>>>>>
>>>>>>> We just need a trusted SHA1PRNG, right? then we can open signed
>>>>>>> providers' jars and get any others.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Tim
>>>>>>>
>>>>>>>
>>>>> --
>>>>>
>>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: verifying signed jars
Posted by Mikhail Loenko <ml...@gmail.com>.
The sources would be good - we would be able to fix bugs quickly and replace
parts of implementation for example where our code is faster.
Thanks,
Mikhail
On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Heh. Everything we will do is legal :)
>
> The point is - would taking some source from BC be the smart thing to do
> - would it be complete, and what kind of maintenance burden would this
> be going forward? Would some kind of re-packaged artifact from the BC
> project itself be better?
>
> Do we need source? Could we have a step where we re-package BC code in
> a form more suited for our purposes?
>
> geir
>
> Mikhail Loenko wrote:
> > We can if it is legal
> >
> > Thanks,
> > Mikhail
> >
> > On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> So I'll ask the obvious - can we borrow some of this from BC?
> >>
> >> Stepan Mishura wrote:
> >>> We should have at least to verify BC provider:
> >>> 1) Message digest algorithm: SHA-1
> >>> 2) Signature algorithm: SHA1withDSA
> >>>
> >>> Other jars may require additional algorithms, for example, SHA1withRSA. We
> >>> can verify BC provider first and use it for further jar verifications.
> >>>
> >>> Thanks,
> >>> Stepan Mishura
> >>> Intel Middleware Products Division
> >>>
> >>>
> >>>
> >>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
> >>>> Hi Tim,
> >>>>
> >>>> In order to verify the signature of those signed provider jars I believe
> >>>> that you would also need trusted implementations of :
> >>>>
> >>>> * SHA-1 and MD5 digest algorithms
> >>>> * DSA and RSA signature algorithms
> >>>>
> >>>>
> >>>> Best regards,
> >>>> George
> >>>> IBM UK
> >>>>
> >>>>
> >>>> Tim Ellison wrote:
> >>>>> Stepan Mishura wrote:
> >>>>> <snip>
> >>>>>
> >>>>>> Returning back to the 'missing post'. I agreed with suggestion but
> >>>> currently
> >>>>>> we don't have Harmony provider so we should define how we locate
> >>>> 'trusted
> >>>>>> provides' to be secure.
> >>>>>>
> >>>>> We just need a trusted SHA1PRNG, right? then we can open signed
> >>>>> providers' jars and get any others.
> >>>>>
> >>>>> Regards,
> >>>>> Tim
> >>>>>
> >>>>>
> >>>
> >>> --
> >>>
> >
> >
>
Re: verifying signed jars
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Heh. Everything we will do is legal :)
The point is - would taking some source from BC be the smart thing to do
- would it be complete, and what kind of maintenance burden would this
be going forward? Would some kind of re-packaged artifact from the BC
project itself be better?
Do we need source? Could we have a step where we re-package BC code in
a form more suited for our purposes?
geir
Mikhail Loenko wrote:
> We can if it is legal
>
> Thanks,
> Mikhail
>
> On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> So I'll ask the obvious - can we borrow some of this from BC?
>>
>> Stepan Mishura wrote:
>>> We should have at least to verify BC provider:
>>> 1) Message digest algorithm: SHA-1
>>> 2) Signature algorithm: SHA1withDSA
>>>
>>> Other jars may require additional algorithms, for example, SHA1withRSA. We
>>> can verify BC provider first and use it for further jar verifications.
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>>>> Hi Tim,
>>>>
>>>> In order to verify the signature of those signed provider jars I believe
>>>> that you would also need trusted implementations of :
>>>>
>>>> * SHA-1 and MD5 digest algorithms
>>>> * DSA and RSA signature algorithms
>>>>
>>>>
>>>> Best regards,
>>>> George
>>>> IBM UK
>>>>
>>>>
>>>> Tim Ellison wrote:
>>>>> Stepan Mishura wrote:
>>>>> <snip>
>>>>>
>>>>>> Returning back to the 'missing post'. I agreed with suggestion but
>>>> currently
>>>>>> we don't have Harmony provider so we should define how we locate
>>>> 'trusted
>>>>>> provides' to be secure.
>>>>>>
>>>>> We just need a trusted SHA1PRNG, right? then we can open signed
>>>>> providers' jars and get any others.
>>>>>
>>>>> Regards,
>>>>> Tim
>>>>>
>>>>>
>>>
>>> --
>>>
>
>
Re: verifying signed jars
Posted by Mikhail Loenko <ml...@gmail.com>.
We can if it is legal
Thanks,
Mikhail
On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> So I'll ask the obvious - can we borrow some of this from BC?
>
> Stepan Mishura wrote:
> > We should have at least to verify BC provider:
> > 1) Message digest algorithm: SHA-1
> > 2) Signature algorithm: SHA1withDSA
> >
> > Other jars may require additional algorithms, for example, SHA1withRSA. We
> > can verify BC provider first and use it for further jar verifications.
> >
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
> >
> > On 2/10/06, George Harley <ge...@googlemail.com> wrote:
> >> Hi Tim,
> >>
> >> In order to verify the signature of those signed provider jars I believe
> >> that you would also need trusted implementations of :
> >>
> >> * SHA-1 and MD5 digest algorithms
> >> * DSA and RSA signature algorithms
> >>
> >>
> >> Best regards,
> >> George
> >> IBM UK
> >>
> >>
> >> Tim Ellison wrote:
> >>> Stepan Mishura wrote:
> >>> <snip>
> >>>
> >>>> Returning back to the 'missing post'. I agreed with suggestion but
> >> currently
> >>>> we don't have Harmony provider so we should define how we locate
> >> 'trusted
> >>>> provides' to be secure.
> >>>>
> >>> We just need a trusted SHA1PRNG, right? then we can open signed
> >>> providers' jars and get any others.
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>>
> >>
> >
> >
> > --
> >
>
Re: verifying signed jars
Posted by Geir Magnusson Jr <ge...@pobox.com>.
So I'll ask the obvious - can we borrow some of this from BC?
Stepan Mishura wrote:
> We should have at least to verify BC provider:
> 1) Message digest algorithm: SHA-1
> 2) Signature algorithm: SHA1withDSA
>
> Other jars may require additional algorithms, for example, SHA1withRSA. We
> can verify BC provider first and use it for further jar verifications.
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
>
> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>> Hi Tim,
>>
>> In order to verify the signature of those signed provider jars I believe
>> that you would also need trusted implementations of :
>>
>> * SHA-1 and MD5 digest algorithms
>> * DSA and RSA signature algorithms
>>
>>
>> Best regards,
>> George
>> IBM UK
>>
>>
>> Tim Ellison wrote:
>>> Stepan Mishura wrote:
>>> <snip>
>>>
>>>> Returning back to the 'missing post'. I agreed with suggestion but
>> currently
>>>> we don't have Harmony provider so we should define how we locate
>> 'trusted
>>>> provides' to be secure.
>>>>
>>> We just need a trusted SHA1PRNG, right? then we can open signed
>>> providers' jars and get any others.
>>>
>>> Regards,
>>> Tim
>>>
>>>
>>
>
>
> --
>
Re: verifying signed jars
Posted by George Harley <ge...@googlemail.com>.
Hi Mikhail,
Mikhail Loenko wrote:
> More implementatoins we have in Harmony - less we depend on third parties.
>
> I think SHA-1 and DSA is something to start with.
>
> Makes sense?
>
Makes sense.
> Thanks,
> Mikhail
>
> On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>
>> Hi Stepan,
>>
>> In the short term, yes, SHA-1 and DSA should suffice for verifying the
>> BouncyCastle provider jar. Long term though, Harmony will also need to
>> support the MD5 and RSA algorithms for other providers that may have
>> been signed with those algorithms. While the Jar file specification does
>> not mandate a set of digest and signature algorithms that may be used
>> for signing, it should be noted that the reference jarsigner tool
>> supports both DSA+SHA-1 and RSA+MD5.
>>
>> Best regards,
>> George
>> IBM UK
>>
>> PS, Keeping my fingers crossed this ends up on the dev-list :-)
>>
>>
>> Stepan Mishura wrote:
>>
>>> We should have at least to verify BC provider:
>>> 1) Message digest algorithm: SHA-1
>>> 2) Signature algorithm: SHA1withDSA
>>>
>>> Other jars may require additional algorithms, for example,
>>> SHA1withRSA. We can verify BC provider first and use it for further
>>> jar verifications.
>>>
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>> On 2/10/06, *George Harley* <george.c.harley@googlemail.com
>>> <ma...@googlemail.com>> wrote:
>>>
>>> Hi Tim,
>>>
>>> In order to verify the signature of those signed provider jars I
>>> believe
>>> that you would also need trusted implementations of :
>>>
>>> * SHA-1 and MD5 digest algorithms
>>> * DSA and RSA signature algorithms
>>>
>>>
>>> Best regards,
>>> George
>>> IBM UK
>>>
>>>
>>> Tim Ellison wrote:
>>> > Stepan Mishura wrote:
>>> > <snip>
>>> >
>>> >> Returning back to the 'missing post'. I agreed with suggestion
>>> but currently
>>> >> we don't have Harmony provider so we should define how we
>>> locate 'trusted
>>> >> provides' to be secure.
>>> >>
>>> >
>>> > We just need a trusted SHA1PRNG, right? then we can open signed
>>> > providers' jars and get any others.
>>> >
>>> > Regards,
>>> > Tim
>>> >
>>> >
>>>
>>>
>>>
>>>
>>> --
>>>
>>
>
>
Best regards,
George
Re: verifying signed jars
Posted by Mikhail Loenko <ml...@gmail.com>.
More implementatoins we have in Harmony - less we depend on third parties.
I think SHA-1 and DSA is something to start with.
Makes sense?
Thanks,
Mikhail
On 2/10/06, George Harley <ge...@googlemail.com> wrote:
> Hi Stepan,
>
> In the short term, yes, SHA-1 and DSA should suffice for verifying the
> BouncyCastle provider jar. Long term though, Harmony will also need to
> support the MD5 and RSA algorithms for other providers that may have
> been signed with those algorithms. While the Jar file specification does
> not mandate a set of digest and signature algorithms that may be used
> for signing, it should be noted that the reference jarsigner tool
> supports both DSA+SHA-1 and RSA+MD5.
>
> Best regards,
> George
> IBM UK
>
> PS, Keeping my fingers crossed this ends up on the dev-list :-)
>
>
> Stepan Mishura wrote:
> >
> > We should have at least to verify BC provider:
> > 1) Message digest algorithm: SHA-1
> > 2) Signature algorithm: SHA1withDSA
> >
> > Other jars may require additional algorithms, for example,
> > SHA1withRSA. We can verify BC provider first and use it for further
> > jar verifications.
> >
> >
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
> >
> >
> > On 2/10/06, *George Harley* <george.c.harley@googlemail.com
> > <ma...@googlemail.com>> wrote:
> >
> > Hi Tim,
> >
> > In order to verify the signature of those signed provider jars I
> > believe
> > that you would also need trusted implementations of :
> >
> > * SHA-1 and MD5 digest algorithms
> > * DSA and RSA signature algorithms
> >
> >
> > Best regards,
> > George
> > IBM UK
> >
> >
> > Tim Ellison wrote:
> > > Stepan Mishura wrote:
> > > <snip>
> > >
> > >> Returning back to the 'missing post'. I agreed with suggestion
> > but currently
> > >> we don't have Harmony provider so we should define how we
> > locate 'trusted
> > >> provides' to be secure.
> > >>
> > >
> > > We just need a trusted SHA1PRNG, right? then we can open signed
> > > providers' jars and get any others.
> > >
> > > Regards,
> > > Tim
> > >
> > >
> >
> >
> >
> >
> > --
>
>
Re: verifying signed jars
Posted by George Harley <ge...@googlemail.com>.
Hi Stepan,
In the short term, yes, SHA-1 and DSA should suffice for verifying the
BouncyCastle provider jar. Long term though, Harmony will also need to
support the MD5 and RSA algorithms for other providers that may have
been signed with those algorithms. While the Jar file specification does
not mandate a set of digest and signature algorithms that may be used
for signing, it should be noted that the reference jarsigner tool
supports both DSA+SHA-1 and RSA+MD5.
Best regards,
George
IBM UK
PS, Keeping my fingers crossed this ends up on the dev-list :-)
Stepan Mishura wrote:
>
> We should have at least to verify BC provider:
> 1) Message digest algorithm: SHA-1
> 2) Signature algorithm: SHA1withDSA
>
> Other jars may require additional algorithms, for example,
> SHA1withRSA. We can verify BC provider first and use it for further
> jar verifications.
>
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
>
> On 2/10/06, *George Harley* <george.c.harley@googlemail.com
> <ma...@googlemail.com>> wrote:
>
> Hi Tim,
>
> In order to verify the signature of those signed provider jars I
> believe
> that you would also need trusted implementations of :
>
> * SHA-1 and MD5 digest algorithms
> * DSA and RSA signature algorithms
>
>
> Best regards,
> George
> IBM UK
>
>
> Tim Ellison wrote:
> > Stepan Mishura wrote:
> > <snip>
> >
> >> Returning back to the 'missing post'. I agreed with suggestion
> but currently
> >> we don't have Harmony provider so we should define how we
> locate 'trusted
> >> provides' to be secure.
> >>
> >
> > We just need a trusted SHA1PRNG, right? then we can open signed
> > providers' jars and get any others.
> >
> > Regards,
> > Tim
> >
> >
>
>
>
>
> --
Re: verifying signed jars
Posted by Stepan Mishura <st...@gmail.com>.
We should have at least to verify BC provider:
1) Message digest algorithm: SHA-1
2) Signature algorithm: SHA1withDSA
Other jars may require additional algorithms, for example, SHA1withRSA. We
can verify BC provider first and use it for further jar verifications.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 2/10/06, George Harley <ge...@googlemail.com> wrote:
>
> Hi Tim,
>
> In order to verify the signature of those signed provider jars I believe
> that you would also need trusted implementations of :
>
> * SHA-1 and MD5 digest algorithms
> * DSA and RSA signature algorithms
>
>
> Best regards,
> George
> IBM UK
>
>
> Tim Ellison wrote:
> > Stepan Mishura wrote:
> > <snip>
> >
> >> Returning back to the 'missing post'. I agreed with suggestion but
> currently
> >> we don't have Harmony provider so we should define how we locate
> 'trusted
> >> provides' to be secure.
> >>
> >
> > We just need a trusted SHA1PRNG, right? then we can open signed
> > providers' jars and get any others.
> >
> > Regards,
> > Tim
> >
> >
>
>
--
Re: verifying signed jars
Posted by George Harley <ge...@googlemail.com>.
Hi Tim,
In order to verify the signature of those signed provider jars I believe
that you would also need trusted implementations of :
* SHA-1 and MD5 digest algorithms
* DSA and RSA signature algorithms
Best regards,
George
IBM UK
Tim Ellison wrote:
> Stepan Mishura wrote:
> <snip>
>
>> Returning back to the 'missing post'. I agreed with suggestion but currently
>> we don't have Harmony provider so we should define how we locate 'trusted
>> provides' to be secure.
>>
>
> We just need a trusted SHA1PRNG, right? then we can open signed
> providers' jars and get any others.
>
> Regards,
> Tim
>
>
verifying signed jars (was: Re: FYI missing mail)
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
<snip>
> Returning back to the 'missing post'. I agreed with suggestion but currently
> we don't have Harmony provider so we should define how we locate 'trusted
> provides' to be secure.
We just need a trusted SHA1PRNG, right? then we can open signed
providers' jars and get any others.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: FYI missing mail
Posted by Stepan Mishura <st...@gmail.com>.
On 2/10/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> Tim Ellison wrote:
> > George Harley wrote:
> > <snip>
> >> The post I want to refer to does not seem to be in the
> >> mailing list archive (!!??!)
> >
> > I don't remember you saying that (and I would have remembered such an
> > eloquent and considered post ;-) )
>
> I didn't get it either, and as he George said, it's not in the archive.
>
> If anyone got it, can you let us know here (and once someone says they
> got it, everyone else stop telling us - we just need to know if anyone
> got it...)
I got it. I thought it was done intentionally: George sent it directly to me
only ... so it is not in the list.
Returning back to the 'missing post'. I agreed with suggestion but currently
we don't have Harmony provider so we should define how we locate 'trusted
provides' to be secure.
Thanks,
Stepan Mishura
Intel Middleware Products Division
geir
>
> >
> > I still have mail that far back in my reader, and it looks like I didn't
> > get it either. Maybe it never hit the list.
> >
> > p.s. +1 to the comment BTW
> >
> > Regards,
> > Tim
> >
> >> so let me copy the relevant text in-line
> >> here as I believe that what it says is important :
> >>
> >> --- snip from dev-list append of 1st Feb 2006 by
> >> george.c.harley@googlemail.com ---
> >>
> >> Just to clarify your clarification of the question of current Harmony
> >> behaviour ...
> >>
> >> (A) With the current Harmony build it looks like there is *no attempt*
> >> to verify the signature of a signed jar file that has been placed on
> the
> >> bootclasspath. I know this because I took a signed BC provider jar (as
> >> downloaded from http://www.bouncycastle.org), deliberately tampered
> with
> >> the .SF file in the META-INF folder by removing a few lines, then added
> >> the modified jar to the bootclasspath of a simple program that listed
> >> the algorithms supported by the BC provider. Everything worked fine.
> >>
> >> (B) With the current Harmony build it looks like an attempt is made at
> >> verifying the signature of a signed jar in the jre/lib/ext directory.
> >> The attempt fails because it involves trying to use functionality
> >> exported by the jar currently being verified and so opens up a whole
> >> problem with cycles.
> >> To my mind, (B) is a definite bug that would be fixed by having a
> >> default Harmony provider. The result of my little bit of playing with
> >> (A) just reinforces the argument that relying on the bootclasspath to
> >> load your third party providers is not er ... secure.
> >>
> >>
> >> --- end of snip from dev-list append of 1st Feb 2006 by
> >> george.c.harley@googlemail.com ---
> >>
> >>
> >> Best regards,
> >> George
> >> IBM UK
> >>
> >>
> >> Geir Magnusson Jr wrote:
> >>>
> >>> Tim Ellison wrote:
> >>>> Arghhh!
> >>>>
> >>>> make it stop
> >>>>
> >>>>> From below:
> >>>> -Xbootclasspath/a:${build.path}/tests${path.separator}${
> env.CLASSPATH}
> >>>>
> >>>>
> >>>> putting the CLASSPATH onto the bootclasspath. What are you smokin'
> ?!
> >>> That was the patch :)
> >>>
> >>> All that really is supposed to do is get junit and bcprov there. I'll
> >>> move.
> >>>
> >>> geir
> >>>
> >>>>
> >>>> [ I know you are fixing this stuff, but I needed to vent ]
> >>>>
> >>>>
> >>>> -------- Original Message --------
> >>>> Subject: svn commit: r376144 -
> >>>>
> /incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
> >>>>
> >>>> Date: Thu, 09 Feb 2006 01:44:21 -0000
> >>>> From: geirm@apache.org
> >>>> Reply-To: harmony-dev@incubator.apache.org
> >>>> To: harmony-commits@incubator.apache.org
> >>>>
> >>>> Author: geirm
> >>>> Date: Wed Feb 8 17:44:19 2006
> >>>> New Revision: 376144
> >>>>
> >>>> URL: http://svn.apache.org/viewcvs?rev=376144&view=rev
> >>>> Log:
> >>>> put the bootclasspath stuff back for classlib tests
> >>>> because as I'm renaming some tests, it appears that
> >>>> when things reordered, tests broke. On a lark, I put
> >>>> it back, and things work. Scary.
> >>>>
> >>>> Will investigate further, but wanted to fix so tests run
> >>>>
> >>>> Also, changed one of the exclusion lists due to renaming.
> >>>>
> >>>>
> >>>> Modified:
> >>>>
> >>>>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
> >>>>
> >>>>
> >>>> Modified:
> >>>>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
> >>>>
> >>>> URL:
> >>>>
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml?rev=376144&r1=376143&r2=376144&view=diff
> >>>>
> >>>>
> ==============================================================================
> >>>>
> >>>> ---
> >>>>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
> >>>>
> >>>> (original)
> >>>> +++
> >>>>
> incubator/harmony/enhanced/classlib/trunk/modules/security2/make/build.xml
> >>>>
> >>>> Wed Feb 8 17:44:19 2006
> >>>> @@ -499,6 +499,8 @@
> >>>> <env key="JAVA_HOME" value="${vm.home}"/>
> >>>>
> >>>> <!-- to pick up junit.jar and bouncycastle.jar -->
> >>>> + <jvmarg
> >>>> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${
> path.separator}${build.jars.path}/x_net.jar"/>
> >>>>
> >>>> +
> >>>> <jvmarg
> >>>> value="-Xbootclasspath/a:${build.path}/tests${path.separator}${
> env.CLASSPATH}"/>
> >>>>
> >>>>
> >>>> <jvmarg
> >>>> value="-
> Djava.security.properties==${build.lib.path}/security/java.security"/>
> >>>>
> >>>> @@ -518,7 +520,7 @@
> >>>> <exclude
> >>>> name="org/apache/harmony/security/test/**"/>
> >>>> <!-- Harmony exclude list
> -->
> >>>> - <exclude
> >>>> name="java/security/AlgorithmParameterGeneratorTest1.java"/>
> >>>> + <exclude
> >>>> name="java/security/AlgorithmParameterGenerator1Test.java"/>
> >>>> <exclude
> name="java/security/KSBuilderTest.java"/>
> >>>> <exclude
> >>>> name="java/security/KeyPairGeneratorTest1.java"/>
> >>>> <exclude
> >>>> name="java/security/KeyPairGeneratorTest3.java"/>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division