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

[Jiri Vanek]

On 02/28/2014 04:15 PM, Andrew Azores wrote:
> 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.

I have already noted some issues when BeforClass throw an exception. If something will be noted....

>
>>
>> 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.

marking your words ;)

>
>>
>> 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.

Yes this was also my background idea. That suddnely( without letting user know) will be allowed 
newly partialy signed applet.

Your reply  persuaded me to the  "definitely requires extra work to be done" as I noted.

>
>>  - 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.

The backward compatibility will not be issue. Issue is to design it properly for new usecases :)

>
> "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.
>


Ok for head, some more work needed before 1.5 release.