[fyi][icedtea-web] backend and itw-settings for extended applets security

[Jiri Vanek]

On 02/21/2013 11:07 PM, Adam Domurad wrote:
> On 02/20/2013 04:53 PM, Adam Domurad wrote:
>> Here are some proposed fixes. Thanks.
>>
>> - comapre -> compare typo fix
>> - Never return from a finally block! (Eclipse underlines the whole finally block as a warning.)
>> See http://weblogs.java.net/blog/staufferjames/archive/2007/06/_dont_return_in.html
>> - Added a null check so we don't compare if a null archive list is stored.
>>
>> - Adam
>>
>>
>
> Ignore that one, this trumps it.
>
> OK. I tried to separate what would be considered changes to Jiri's part out.
> AppletSecuritySettings.java had to be moved out of sun.applet to make it accessible.
>
> First apply Jiris latest patch, then the rest of them with integrated-dialogue2.patch last.
>
> Here are the patches. Will make a ChangeLog sometime soon.
>
> All the applet security levels should be working in this patch, as well it should honour the global
> applet settings.
>
> Red/green text indicates if you've accepted a patch before.
>
> Further implementation question:
> - Currently when many applets share a single classloader on a page and one is rejected, it'd be nice
> if the it did not ask for rejection for all the other applets. It is tricky to get this right.
> Perhaps rejecting a certain unique key should be permanent for a session ? There should be no harm,
> as you can always restart your browser if you accidentally hit reject. And indeed there is harm in
> the other direction, if you reject an applet but accidentally hit OK for one of the other applet
> dialogues that come up.
>
> Let me know of any issues.
>
> Happy hacking,
> -Adam


ugh. Next round of backend:

My OriginalPatch, added filtering for table and removed mainClass - all as separate changes.
Also agreedChangesToLockingFile.diff ( I agree with your changes, nextTime I will merge them inside)
I have rewritten your strength matching algorithm -  newMAtchByStrength.diff  - I hope it will still 
suits (the only change was actually to returnimidiately when strong match is  found - return first 
week otherwise)

Thanx for suggestions, as Omair suggested - lets fire this! (means merge above, add tests and push)

ps: I hope I have not forget some occurence of mainCLass somewhere :-/
pps: test tests and tests on my side :-/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: removedMainClassForomAllConsiderations.patch
Type: text/x-patch
Size: 20733 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130225/7fcc44c3/removedMainClassForomAllConsiderations.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: agreedChangesToLockingFile.diff
Type: text/x-patch
Size: 1964 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130225/7fcc44c3/agreedChangesToLockingFile.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newMAtchByStrength.diff
Type: text/x-patch
Size: 3429 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130225/7fcc44c3/newMAtchByStrength.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addedFilteringForTable.diff
Type: text/x-patch
Size: 16964 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130225/7fcc44c3/addedFilteringForTable.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: originalPatch.diff
Type: text/x-patch
Size: 124495 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130225/7fcc44c3/originalPatch.diff