Regression in itw from Tue Mar 26
Jiri Vanek
jvanek at redhat.com
Fri Apr 12 06:37:17 PDT 2013
On 04/12/2013 03:01 PM, Adam Domurad wrote:
> Please use [icedtea-web] for filter purposes :-)
>
> On 04/12/2013 06:07 AM, Jiri Vanek wrote:
>> Hi, commit
>>
>> changeset: 656:1c26ce1e1cb3
>> tag: tip
>> user: Adam Domurad <adomurad at redhat.com>
>> date: Tue Mar 26 14:57:33 2013 -0400
>> summary: Integration of unsigned applet confirmation dialogue.
>>
>> broke the
>>
>> CodeBaseClassLoaderTest.testNullFileSecurityDescApplication test
>>
>> The affecting hunk was
>>
>> @@ -596,9 +604,9 @@
>>
>> JARDesc jars[] = resources.getJARs();
>>
>> - if (jars == null || jars.length == 0) {
>> + if (jars.length == 0) {
>>
>> - boolean allSigned = true;
>> + boolean allSigned = (loaders.length > 1) /* has extensions */;
>> for (int i = 1; i < loaders.length; i++) {
>> if (!loaders[i].getSigning()) {
>> allSigned = false;
>>
>> of diff -r bb971f25eb42 -r 1c26ce1e1cb3 netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
>>
>> and the responsible line was
>>
>> - boolean allSigned = true;
>> + boolean allSigned = (loaders.length > 1) /* has extensions */;
>>
>> An I must say I'm hesitating with fix. Just use always true? or use (loaders.length > 0) which is
>> actually the same.
>>
>> Why the change at all?
>
> Without this change, applets that do not have an associated jar will always be considered signed.
> Thus they will always run regardless of unsigned applet trust setting.
> What does the broken test indicate ?
Yah, sorry I should wrote immidiately. Its impact ios really starnge, you are actually removing
"always true" but result is "less security"
Issue is that suddenly JNLPClasslaoder with null security request (== sandbox permissions) started
to return resources.
Before it was not. See the logic of the test and the failure on line 311
>
>>
>> J.
>>
>> see http://10.34.2.200/icedtea-web-dailyreport/ICWDR_1364327226/index.html for full info
>
> -Adam
More information about the distro-pkg-dev
mailing list