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

Jiri Vanek jvanek at redhat.com
Thu Mar 20 19:41:50 UTC 2014


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?

as another changeset this should be somehow fixed.

+       OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL,
=> please MESSAGE_DEBUG

otherwise ok to go:)


More information about the distro-pkg-dev mailing list