harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: FYI missing mail
Date Fri, 10 Feb 2006 10:27:18 GMT
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 
<mailto:george.c.harley@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 <geir@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>

Mime
View raw message