[icedtea-web] URLPermission in Java 8

Jiri Vanek jvanek at redhat.com
Thu Jun 19 08:34:15 UTC 2014


On 06/18/2014 08:03 PM, Andrew Azores wrote:
> On 06/18/2014 01:02 PM, Omair Majid wrote:
>> * Andrew Azores <aazores at redhat.com> [2014-06-18 12:54]:
>>> On 06/18/2014 12:04 PM, Omair Majid wrote:
>>>> * Andrew Azores <aazores at redhat.com> [2014-06-18 10:04]:
>>>>> This patch can't compile with Java 7
>>>>
>>>> I guess the question to ask is, do you want something built with Java 7
>>>> to just work on Java 7? Or do you want the same build to work with both
>>>> Java 7 and 8?
>>>>
>>>> If it's the first, then a compile-time switch to optionally compile a
>>>> 8-specific class that handles this responsibility seems appropriate.
>>>> This is what we did for the X509TrustManager with 6/7 support. If you
>>>> want the second option, then you probably have to use reflection to work
>>>> around the issue.
>>>
>>> Right, this is something I have no informed opinion on.
>>
>> Jiri might know more about this. Getting one (compiled) version of
>> Icedtea-Web to work with multiple Java versions selectable at runtime is
>> a goal for future (next?) release.
>
> It sounded like he was hinting at that but I guess we'll wait for tomorrow and his clarification
> before putting any more work into this.

Both parts of this are practically done.

But already now, when you built with 7, you can select 6 and it will not work properly.
  - we use (in head)
   export IT_LANGUAGE_SOURCE_VERSION=7
   export IT_CLASS_TARGET_VERSION=7
   - so the bytecode will be refused by 6 (?)
  - there is the 6 and 7 trust managers decided in compiletime

But above issue do not count against compiled by 7 and run in 8.

Personally , until jdk9 comes out, I would like to support 8 and 7.

That means build
   export IT_LANGUAGE_SOURCE_VERSION=7
   export IT_CLASS_TARGET_VERSION=7
and run in both 7 and 8.
  - and having only seventh's trust manager

That leads to refelction solution.


As for 1.5 this is a bit more compilcated,a nd we need to solve it.
In 1.5 we
   export IT_LANGUAGE_SOURCE_VERSION=6
   export IT_CLASS_TARGET_VERSION=6
And canbe built with both 6 and 7 trust manager

built by 6 - the six's manager is used
built by 7 or 8  - the seventh's manager is used

So the reflection solution should be ok here. More discus sable is whether 1.5 should be 8 
compatible. But IMO - should be. I'm afraid 1.6 will not be out soon, and jdk8 is already alive.

J.


>
>>
>>>>> is also probably too lenient about the URLPermission it's
>>>>> granting, which allows any request method with any headers to any resource
>>>>> recursively and inclusively in the applet codebase.
>>>>
>>>> Isn't that expected?
>>>
>>> I don't know. That's the first thing I think we need to figure out. The
>>> actual result does indeed match exactly what I intended and expected for it
>>> to do, but I don't know if this is actually the right thing to do.
>>
>> I think we should follow the Same Origin Policy [1][2][3] model used by
>> browsers and not be more restrictive unless there's a very very good
>> reason to.
>>
>> Thanks,
>> Omair
>>
>> [1] http://icedtea.classpath.org/wiki/IcedTea-Web#Same_Origin_Policy
>> [2] http://en.wikipedia.org/wiki/Same-origin_policy
>> [3] https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
>>
>
> Okay, so I guess my gut feeling on the permission was actually pretty much right on :)
>
> Thanks,



More information about the distro-pkg-dev mailing list