[rfc][icedtea-web] Trusted-only manifest attribute

[Andrew Azores]

On 03/20/2014 03:41 PM, Jiri Vanek wrote:
> On 03/20/2014 08:08 PM, Andrew Azores wrote:
>> On 03/20/2014 01:32 PM, Jiri Vanek wrote:
>>> + OutputController.getLogger().log(OutputController.Level.ERROR_ALL,
>>> + "Trusted Only manifest attribute is \"true\". " + signedMsg + " 
>>> and requests permission level: " + securityType);
>>>
>>> Please, do it MESSAGE_DEBUG
>>>
>>>
>>>
>>> On 03/20/2014 05:42 PM, Andrew Azores wrote:
>>>> On 03/20/2014 12:23 PM, Jiri Vanek wrote:
>>>>> On 03/20/2014 04:33 PM, Andrew Azores wrote:
>>>>
>>>>>
>>> ...
>>>>>
>>>>>
>>>>> The reproducer is missing javaws parts and is missing correct 
>>>>> case. Minimalistical reproducer should be
>>>>> - applet signed trusted-only=false
>>>>> - applet signed trusted-only=true
>>>>> - applet signed trusted-only=illegal
>>>>> - applet mixed signatures trusted-only=false
>>>>> - applet mixed signatures trusted-only=false
>>>>> - applet mixed signatures trusted-only=illegal
>>>>> - applet not signed trusted-only=false
>>>>> - applet not signed trusted-only=true
>>>>> - applet not signed trusted-only=illegal
>>>>> - javaws signed trusted-only=false
>>>>> - javaws signed trusted-only=true
>>>>> - javaws signed trusted-only=illegal
>>>>> - javaws not signed trusted-only=false
>>>>> - javaws not signed trusted-only=true
>>>>> - javaws not signed trusted-only=illegal
>>>
>>> the specifying x not specifying all security is doubling the actual 
>>> work on this :(
>>>>>
>>>>> However it is to much work. In long-term it would be nice to have 
>>>>> them. For now, just extends your:
>>>>> applet not signed trusted-only=true
>>>>> by:
>>>>> javaws not signed trusted-only=true
>>>>
>>>> It's:
>>>> applet signed trusted-only=true
>>>> right now. But yes. JNLP version of the same added.
>>> > It will need to be custom eventually for the mixed signatures, 
>>> though. I was intending to use just one custom reproducer to build 
>>> and test all of the different cases (eventually).
>>>
>>>
>>> I see. Than please add the unsigned + trusted-only=true (it should 
>>> be one line in makefile and two more tests in testcase)
>>>
>>> Also maybe add the Assert for presence of " 
>>> System.out.println("TrustedOnlyAttribute applet running");" ?
>>>
>>> Also please add one html and one jnlp file witch will request the 
>>> all permissions. (So the only "passing" pair of tests)
>>> and one html and one jnlp file witch will request the all 
>>> permissions, but will not be signed.
>>>
>>> Assuming those eight reproducers behave corrctly ( signed + 
>>> requesting, signed + not requesting, not signed + requesting, 
>>> notsigned + not requesting)*(jnlp+html), all trusted-only=true
>>> and above MESSAGE_DEBUG fixed. Go on and push!
>>>
>>>
>>
>> Hmm, seems like checking for the SecurityDesc of plugin applets is 
>> not very useful. I've cut it down to 6 test cases here (all 
>> specifying Trusted-only: true), which I think is probably okay for now.
> Is not?-) I was wondering from where the initial idea come....
>
>>
>> The actual attribute check changed a little because I ran into an NPE 
>> and did a very very small refactor as well.
>>
>> Thanks,
>>
>
> What about the issue with sandbox - the same as in case of permissions 
> att. Or not?

Yea. It should be sufficient to just add that condition for the 
isFullySigned variable. Either the applet is actually fully signed, or 
it's partially signed and the SecurityDelegate says the user manually 
chose to run in sandbox.

>
> as another changeset this should be somehow fixed.
>
> + OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL,
> => please MESSAGE_DEBUG
>
> otherwise ok to go:)

Crap :) I was using this for myself for debugging the tests, and forgot 
to put it back. Sorry!

Thanks,

-- 
Andrew A