[rfc][icedtea-web] Fix support for signed applets with sandbox permissions in manifest

[Jiri Vanek]

On 06/19/2014 04:38 PM, Andrew Azores wrote:
> On 06/19/2014 10:23 AM, Jiri Vanek wrote:
>> On 06/19/2014 04:11 PM, Andrew Azores wrote:
>>> On 06/18/2014 01:44 PM, Andrew Azores wrote:
>>>> On 06/18/2014 12:01 PM, Jiri Vanek wrote:
>>>>> On 05/27/2014 06:23 PM, Andrew Azores wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This patch allows signed applets with sandbox permissions specified in
>>>>>> their manifests to actually
>>>>>
>>>>>
>>>>> How it is dealing with mixed (signed + unsigned code) apps?
>>>>
>>>> I don't have any examples of mixed signing apps with a Permissions manifest attribute, but a
>>>> reproducer could be prepared for this case.
>>>>
>>>
>>> Quick progress update: I'm working with Lukasz on creating this reproducer, since it's a good
>>> example of a fairly complicated reproducer test. Once that's ready then it can go into a changeset
>>> along with the already provided test. This will cover fully signed and partially signed applets,
>>> both with Permissions: sandbox in the manifest.
>>>
>>> Which other possible combinations of Signing x Manifest x Plugin/JNLP are worthy of testing? Plugin
>>> vs JNLP does have a distinction in the Permissions attribute spec, so that should probably be
>>> tested. Signing of course needs to be done, but fully vs partially is probably sufficient, since
>>> unsigned applets are only allowed to be sandboxed anyway. Do we also want to have tests for
>>> Permissions: all-permission in the manifest? And the case of no manifest permissions attribute at
>>> all is pretty well covered already by a lot of other reproducers (eg MixedSigningApplet and
>>> CustomPoliciesTest) IMO.
>>>
>>
>> There can be nitpicks like jnlp app diverged to be lunched as applet/app and also html applet
>> which can be lunched via jnlp href.
>>
>> It is another x 3 :(
>>> So {Fully Signed, Partially Signed} x {Permissions: sandbox, Permissions: all-permission} X {Plugin,
>>> JNLP} ?
>>
>> Well this is really a lot of work. On one side I would be happy to have them all, on second, I
>> would call it to much work (but may be good practice for Lukas ;) ).
>>
>> Please dont forget to closing listeners otherwise the testsuite will run another 10minutes longer;)
>>
>> Well all 12 reproducers  (+ 6*4 for applets)is ideal world. If you will have them all it really
>> will be nice, but do not waste more time then is necessary.
>>
>> Ty!
>>
>>
>> J.
>
> Yes, that is definitely a lot of work. It is an important region to have rigorous testing for though.
>

Then you really can multiple it also by {jnlp app, jnlp applet, html applet, html+jnlp-href} cases
>>
>>
>> hmm Jsut crossed my mind - Most of the reproducers have no manifest at all. (So issiing
>> permissions attribute). The "daily" report  runs with the manifest check off. And on low security.
>> I'm guessing it will not be affected by your chnageser (I'm pretty sure, but confirming)
>>
>>
>> J.
>>
>
> Yea, that's a big concern. Disabling the manifest checks means that none of the reproducer tests
> will ever be auto-sandboxed, regardless of what's in the manifest, so all the tests are invalidated :(
>

Ok. This will  need (my) tuning on side of reproducers engine. Or at least on side of daily test.