[rfc][icedtea-web] Signed applets with codebase loading

Jiri Vanek jvanek at redhat.com
Wed Feb 26 08:37:16 PST 2014


On 02/26/2014 04:41 PM, Andrew Azores wrote:
> On 02/14/2014 11:23 AM, Andrew Azores wrote:
>> On 02/13/2014 09:50 AM, Jiri Vanek wrote:
>>> Hi!
>>>
>>>
>>> Changes to classlaoder looks ok, but test do not work:
>>>
>>> Passed: SignedAppletCodebaseLoadingTests.testCodebaseLoading - chromium-browser
>>>  - WARNING This test is known to fail, but have passed!
>>> Passed: SignedAppletCodebaseLoadingTests.testCodebaseLoading - opera
>>>  - WARNING This test is known to fail, but have passed!
>>> Passed: SignedAppletCodebaseLoadingTests.testCodebaseLoading - midori
>>>  - WARNING This test is known to fail, but have passed!
>>> Passed: SignedAppletCodebaseLoadingTests.testCodebaseLoading - epiphany
>>>  - WARNING This test is known to fail, but have passed!
>>> FAILED: testSignedAppletWithExternalMainClassLaunch -
>>> chromium-browser(SignedAppletExternalMainClassTest) applet did not initialize
>>>  - This test is known to fail
>>> FAILED: testSignedAppletWithExternalMainClassLaunch - opera(SignedAppletExternalMainClassTest)
>>> applet did not initialize
>>>  - This test is known to fail
>>> FAILED: testSignedAppletWithExternalMainClassLaunch - midori(SignedAppletExternalMainClassTest)
>>> applet did not initialize
>>>  - This test is known to fail
>>> FAILED: testSignedAppletWithExternalMainClassLaunch - epiphany(SignedAppletExternalMainClassTest)
>>> applet did not initialize
>>>  - This test is known to fail
>>> Total tests run: 8; From  those : 8 known to fail
>>> Test known to fail: passed: 4; failed: 4; ignored: 0
>>> Test results: passed: 4; failed: 4; ignored: 0
>>>
>>>
>>>
>>> why???
>>>
>>> (after removal of exception)
>>> After reading description, whole thread,and code, the second four should also pass....
>>
>> Well, this is incredibly embarrassing. The latest commit (mine) to head introduces this regression
>> - external main-class is broken now. :(
>>
>> At the time this patch was originally sent, that test would've been working, but it wasn't present
>> for regression testing against that latest commit, so things broke...
>>
>>>
>>> minor note:
>>> > +    private static void assertNoExceptions(ProcessResult pr) {
>>> > +        assertFalse(pr.stdout.contains("xception"));
>>> > +        assertFalse(pr.stderr.contains("xception"));
>>> > +    }
>>>
>>> Please , don't do this. I spent large amount of time in removal of all those.
>>> nor do assertTrue(pr.stderr.contains("xception"));. Unless you are searching for
>>> appearence/notappearence of some ExactException.
>>
>> Okay, I'll fix this up.
>>
>>>
>>> What about applet, which have few jars signed vith valid signature, and some vith invalid???
>>> Isn't it also partially signed one?
>>> The example is recently discovered reproducer for redirection -
>>> https://java.net/projects/electric/downloads/download/electric.jnlp
>>>
>>> Well it is jnlp app, but in this case it sounds to me like valid....
>>>
>>> What do you think?
>>>
>>
>> I'm not entirely sure what you're asking here. The issues addressed by these patches have to do
>> with loading un-JAR'd classes directly from the codebase - how is this JNLP application connected?
>>
>> Thanks,
>>
>
> Updated patch, everything is hopefully back in order again.
>
> Thanks,
>


Assuming you tested it against failed tests, the changes looks ok to go.


J.


More information about the distro-pkg-dev mailing list