[fyi][icedtea-web] backend and itw-settings for extended applets security

[Adam Domurad]

On 03/22/2013 10:57 AM, Jiri Vanek wrote:
> On 03/20/2013 07:36 PM, Adam Domurad wrote:
>> On 03/15/2013 11:01 AM, Jiri Vanek wrote:
>>> On 03/12/2013 01:56 PM, Adam Domurad wrote:
>>>> On 03/01/2013 12:10 PM, Adam Domurad wrote:
>>>>> [ large snip ]
>>>>>> New version attached.
>>>>>> -Adam
>>>>>
>>>>> Woops. In the back&forth between 1.2 and HEAD I have forgot to add 
>>>>> the normalization stuff.
>>>>>
>>>>> Rough location of the changes (sorry for the odd format, I just 
>>>>> grepped them):
>>>>>
>>>>> + private static UnsignedAppletActionEntry 
>>>>> getMatchingItem(UnsignedAppletActionStorage
>>>>> actionStorage, PluginBridge file) {
>>>>> + return actionStorage.getMatchingItem(
>>>>> + normalizeURLQuietly(file.getSourceLocation()).toString(),
>>>>> + normalizeURLQuietly(file.getCodeBase()).toString(),
>>>>> + file.getArchiveJars());
>>>>> + }
>>>>> +
>>>>> + static private URL normalizeURLQuietly(URL url) {
>>>>> + try {
>>>>> + System.out.println("Normalizing " + url + " to " + 
>>>>> ResourceTracker.normalizeUrl(url, false));
>>>>> + return ResourceTracker.normalizeUrl(url, false);
>>>>> + } catch (IOException e) {
>>>>> + e.printStackTrace();
>>>>> + } catch (URISyntaxException e) {
>>>>> + e.printStackTrace();
>>>>> + }
>>>>> + return url;
>>>>> + }
>>>>> -- 
>>>>> + }
>>>>> +
>>>>> + URL codebase = normalizeURLQuietly(file.getCodeBase());
>>>>> + URL documentbase = normalizeURLQuietly(file.getSourceLocation());
>>>>> +
>>>>> + /* Else, create a new entry */
>>>>> + UrlRegEx codebaseRegex = new UrlRegEx("\\Q" + codebase + "\\E");
>>>>> + UrlRegEx documentbaseRegex = new UrlRegEx("\\Q" + documentbase + 
>>>>> "\\E");
>>>>> +
>>>>> + UnsignedAppletActionEntry entry = new UnsignedAppletActionEntry(
>>>>> + behaviour,
>>>>>
>>>>>
>>>>> Happy hacking,
>>>>> -Adam
>>>>
>>>> Ping?
>>>
>>> Sorry for taking so long, but it was not working as expected.
>>> Few issues remains:
>>> 1)The "wildcard do not work" issue as we have discussed - they do :) 
>>> But i had (for some
>>> reason???) included archives comaprsion also for not stored 
>>> archvies. So when there was wildchards
>>> an no archives, but the matching against fully qualified applet then 
>>> failed. Attached is patch
>>> with fix and test. [rfc]
>>
>> Looks OK to me.
>
> pushed.
>>
>>> 2)parameters - as you are already aware, all parameters are stored 
>>> to urls. As those can be some
>>> dinamical ID  or simialr, then I think we should strip them both 
>>> from  bases and from jars. For
>>> jars the tshe strip is easy (all behind ? , including ?).For urls 
>>> I'm not so sure. Maybe the best
>>> is to strip both saved and compared? or strip just form saved with  
>>> be "...\E.*" or
>>> "...?\E.*addition to such a base? [rfc]
>>
>> Hmm. OK, sounds good (stripping both).
>
> looks like working.
>>
>>>
>>> 3)archives saved with full url. On one side I'm not sure how wrong 
>>> this is. On the second side  I
>>> would probably prefer  to have just plain archive names . This 
>>> happens during all, except "plain
>>> archives tag". Good reproducer is jnlp href. I'm for simple "scratch 
>>> everything before last slash"
>>> - before saving and comparing [rfc]
>>
>>
>> 'Scratch everything before last slash' was not sufficient, but OK 
>> used URI#relativize
>
> Also looks as working axcept the "invalid url" states as we discussed 
> on IRC. Please fix.

I had to ditch URI#relativize as trying to get it to handle invalid URL 
character's was a minefield. We should be fine just matching the start 
of the codebase against the archives URLs, and falling back to storing 
full URL.

>>
>>>
>>>
>>> With fix on my previous work the whole concept looks to be working 
>>> as expected. Maybe you can
>>> push, and fix following issues separately. Depends what do you 
>>> prefer to fight with during
>>> packporting to 1.3;)
>>> Also the "ask once for matching appelts" looks like working,a nd I 
>>> have seen both red and green
>>> text finally :)
>>> I think that also the backport to 1.2 is affected by above issues, 
>>> so I would hold it off.. or
>>> maybe do not do it at all. (and just live with this  1.3 and head)
>>
> Looking forward for this, (as it will allow to "allow several same 
> codebase appelts" at once)!
>> It's easy to fix. I'll do it once we get this in.
>>
>>>
>>>
>>> J.
>>>
>>
>>
>> New version posted. Changes in UnsignedAppletTrustConfirmation.java, 
>> see extractRelativeArchives &
>> normalizeUrlAndStripParams. I also added some extra debug logging.
>
> Please unittest all unitility methods!

I added unit tests for the utility methods. Let me know if there's more 
you want unit tested.

>
>
> hmm... I have found one regression between _3 and _4 - it seems that 
> also signed appelts are being verified for low, high and very high, 
> but they should not be... Is it just my imagination?

I hope so -- it's either that, or ghosts, because I can't reproduce it.

>
>
>
> J.
>

-Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: integrated-dialogue5.patch
Type: text/x-patch
Size: 36845 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130322/8e4a31e7/integrated-dialogue5.patch