Thoughts on possible options to JDK-8027598
Rajan Halade
rajan.halade at oracle.com
Wed Nov 27 21:43:28 UTC 2013
On 11/27/2013 12:47, Bradford Wetmore wrote:
> > jtreg team? I am not aware of one. Jon Gibbons works on this in his
> > spare time.
>
> I would call him "the JTREG team."
>
> Was there an ETA for this? Balancing recent test stabilization
> efforts with this, you may consider consider adding othervm and then
> back it out when the JTREG fix is made.
I am discussing this with Jon and will soon update with summary of it. I
am also working on adding /othervm to affected tests.
- Rajan
>
> Brad
>
>
>
> On 11/25/2013 2:29 AM, Chris Hegarty wrote:
>> On 22/11/13 21:11, Rajan Halade wrote:
>>>
>>> On 11/22/2013 11:42, Sean Mullan wrote:
>>>> On 11/21/2013 04:53 AM, Chris Hegarty wrote:
>>>>>>>> If I am correct, JTREG has support provider cleanup already.
>>>>>>>> But the
>>>>>>>> question is even JTREG reset the providers, it still cannot ensure
>>>>>>>> next
>>>>>>>> test won't be impacted because in some circumstances JDK may
>>>>>>>> need to
>>>>>>>> cache something which depends on previous providers. Still need to
>>>>>>>> analysis the test case by case.
>>>>>>>
>>>>>>> Right, any static or cached data may be invalid, and this will
>>>>>>> require
>>>>>>> careful changes to the JRE itself.
>>>>>> Pardon my ignorance - if I gather correctly then ProvidersSnapshot
>>>>>> library also doesn't sandbox effects completely.
>>>>>
>>>>> FYI. I am not part of the security team, and someone from the
>>>>> security
>>>>> group should ultimately have to agree/disagree, but we have similar
>>>>> issues in other parts of the platform. I don't know the specifics of
>>>>> the
>>>>> code here so it may, or may not, be an issue.
>>>>>
>>>>> If any part of the security framework stores values in static fields,
>>>>> that is dependent on the security providers, then when the providers
>>>>> change this static value may be incorrect.
>>>>>
>>>>> We encounter this from time to time with system properties. E.g. JDK
>>>>> HTTP Client code reads system property and stores in static field,
>>>>> JDK
>>>>> HTTP Client will never never re-read the property as it believes it
>>>>> will
>>>>> not change. Having jtreg reset/clean certain system properties
>>>>> will not
>>>>> help in this case.
>>>>
>>>> Yes, the example with system properties is a good one.
>>>>
>>>> However, providers are designed to be added and removed dynamically
>>>> (see the java.security.Security API), so if there is some static
>>>> information not being cleared when providers are reset, I would tend
>>>> to think it may be a bug in the JDK.
>>
>> OK, if this is the case then that is fine.
>>
>>> yes. thanks!
>>>>
>>>> My preference would be change jtreg to clear/restore providers, and
>>>> more thoroughly analyze any subsequent test failures as it may be a
>>>> bug in the JDK.
>>> Ok, I will follow up with jtreg team to find out when they can
>>> commit to
>>> timeline.
>>
>> jtreg team? I am not aware of one. Jon Gibbons works on this in his
>> spare time. You may want to take a look at jtreg [1] in the code tools
>> project.
>>
>> -Chris.
>>
>> [1] http://openjdk.java.net/projects/code-tools/jtreg/
>>
>>>
>>> - Rajan
>>>>
>>>> --Sean
>>>>
>>>
More information about the security-dev
mailing list