[rfc][icedtea-web] Unsigned applet security dialog abstraction

[Andrew Azores]

On 02/28/2014 06:04 AM, Jiri Vanek wrote:
>
> The renaming patch is ok to go, unless you wont to rename it to 
> general ExecuteAction (see bottom of email)
>
> Code itself looks good. Only nit:
>
> +        } catch (Exception e) {
> +            e.printStackTrace();
> +            throw e;
> +        }
>
> Whats that? print and rethrow:-) why? only one of it should be enough 
> or not. Anyway, print stack trace is forbidden. Use ServerAccess.log* 
> rather.

This is in the tests, right? That's the only place I can find a match in 
the patches. Anyway - not sure what I was doing here, honestly. The 
exception doesn't even need to be caught and printed, does it? It's a 
JUnit @BeforeClass method, so if it throws an exception, will this be 
logged anyway? New tests attached, but the only difference is the 
try/catch there has been removed altogether.

>
> One general comment to idea itself. I was thinking about reusing this 
> dialogue for 
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library 
> (And maybe some more ) but it forces few more generalizations:
>  - it should depend on jnlpfile, not on plugin bridge. (But this 
> should not prevent the dialogue from some cations if it is instance of 
> plugin bridge)\

I already reduced most of the dependency on PluginBridge over JNLPFile, 
but I think with the new abstraction patch I've removed it entirely.

>  - it should use also  title of application
>  - the help have to be adapted
>  (maybe some acces to disable/enable some controls or similar..)
>
> From the quick glance those should be not hard to achieve. Do you wont 
> to include it in this refactoring, or later? Eg when I will use this. 
> Probably something now, something later on demand...

These are both probably worthy but as a separate changeset, especially 
making the controls generally enable/disable-able.

>
> Also in sound of those refactoings, I'm thinking if it is correct to 
> use ExtendedAppletsSecurity table as it is now.
>  - you wont to reuse it for partially signed yes applets yes?

Yes. It already works just fine as far as I've been able to tell in my 
testing. I suppose there might be a conflict if somehow one applet goes 
from being partially signed to unsigned or vice-versa, while it already 
has a remembered entry in the table... I hadn't even thought of that 
case before. It just seems to me that normally there shouldn't be any 
collision having them together in the same table. But your solution 
below helps with this anyway.

>  - I wont to use it for Application-Library-Allowable-Codebase
>  - currently it is used for unsigned applet wont to run
>
> Your usecase is probably ok, and with some compromising it can reuse 
> current table. But definitely not the my one:(

Yours definitely requires extra work to be done ;)

>
> So I was thinking about extending the format for some flag "purpose" 
> (rather then  to have new table)
> eg:
> from current resolution timestamp url-regex jars:
> y 1393582488549 \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E 
> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
> to
> y ACACA 1393582488549 
> \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E 
> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
> or
> y UNSIGNED 1393582488549 
> \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E 
> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
> or
> y PARTIALLY 1393582488549 
> \Qhttp://www.walter-fendt.de/ph14e/forceresol.htm\E 
> \Qhttp://www.walter-fendt.de/ph14_jar/\E Ph14English.jar,ZerlKraft.jar
>
> so:
> resolution purpose timestamp url-regex jars
> or similar,
>
>
> What do you think?
>
>
>
>
>
> J.

This sounds okay, I suppose. It should come with some pretty heaving 
renaming of the action storage classes though, because their names are 
really getting inaccurate with this kind of change. I would like to 
reuse the table if possible rather than create new one(s), and this 
seems like a reasonable way to do it I think? There will need to be some 
"migration" done to the table as well, but older tables that don't have 
this field should just have it filled in with UNSIGNED, so it shouldn't 
be too hard to work out.

"tests2" has the try/catch removed, "abstraction_pluginbridge_deps" just 
changes a few occurrences of PluginBridge to JNLPFile, and "renames" 
hasn't been changed but is included for convenience.

Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: abstraction_pluginbridge_deps.patch
Type: text/x-patch
Size: 31696 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140228/b8cf97f7/abstraction_pluginbridge_deps-0001.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: renames.patch
Type: text/x-patch
Size: 28643 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140228/b8cf97f7/renames-0001.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tests2.patch
Type: text/x-patch
Size: 5891 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140228/b8cf97f7/tests2-0001.patch