[rfc][icedtea-web] Mixed-signing applet permissions (PR1592)

[Jiri Vanek]

On 11/04/2013 09:19 PM, Andrew Azores wrote:
> Hi,
>
> This patch allows signed JARs within mixed-signing applets to be granted full permissions, while
> unsigned JARs in the same applets retain sandbox permissions only. The user is warned/prompted for
> the okay to proceed when this occurs.
>
> I was not able to create a working reproducer test for this due to the following error:
>
> java.lang.SecurityException: class "MixedSigningApplet"'s signer information does not match signer
> information of other classes in the same package
>
> I'd need to have two different packages in use to get around this, but AFAIK we don't have a way to
> support this with our reproducer system. Also, even if I had that working, the
> SecurityDialogs.showNotAllSignedWarningDialog still doesn't really respect the Extended Applet
> Security settings and will appear to prompt the user even if security is set to lowest. This would
> break the automation of the reproducer test and make it fairly useless anyway.
>
> The patch is split in two. The first one does the actual work. The second patch just removes an old
> unused local variable and an associated enclosing try/catch. This indentation change creates hard to
> read diff output, so I included this separately for ease of review. They need to be applied in order.
>
> Changelog:
> * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (initializeResources) grant full
> permissions to signed JARs of mixed-signing applets
>
> Thanks,
>

Hm.. It took time to get through all possible consequences of this patch.
Tbh I'm surpised with simplicity of it.

the "jarSingleton" hack is good enough, but wel. should be more readableas on first glance it is not 
sure what it dies,  - it is not singleton in its true meaning.

"IMO, the right solution would just be moving the logic into the verifier itself" worth to do then?"

"signing" variable is now misleading - it should be in three states.  Eg. some dialogues can have 
changed context then.

I must insist on set of reproducers (not automated, but placed in reproducers direcotries - if they 
will be custom , there can be script to lunch them or something like that)) where you will try to 
hack your own approach. Most basic signed and uunsigned together, unsigned code doing something 
wrong. Or unsigned called signed, which is then doing soemthing wrong.. or similar. No limits to 
imagination :))

Good speed,
   j.