harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: FYI missing mail
Date Fri, 10 Feb 2006 12:29:38 GMT
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 
> <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