NSS configuration & plugin interaction

[Matthias Klose]

On 08.04.2010 20:24, Andrew John Hughes wrote:
> On 8 April 2010 17:54, Matthias Klose<doko at ubuntu.com>  wrote:
>> On 07.04.2010 16:32, Andrew John Hughes wrote:
>>>
>>> On 7 April 2010 01:44, Matthias Klose<doko at ubuntu.com>    wrote:
>>>>
>>>> this is about 461 and 469; when icedtea is configured with --enable-nss,
>>>> just an additional security provider is added in java.security, the code
>>>> currently in icedtea isn't changed, so the behaviour should be
>>>> reproducible
>>>> on systems which have the required nss available.
>>>>
>>>> visiting the page mentioned in 461 with the
>>>> security.provider.9=sun.security.pkcs11.SunPKCS11
>>>> ${java.home}/lib/security/nss.cfg enabled in java.policy, I get the stack
>>>> trace in [1] after closing the page, the java process
>>>> icedteanp-appletviewer-to-plugin sleeps (ignoring the Unimplemented
>>>> messages
>>>> at the end).
>>>>
>>>
>>> This isn't the same failure as 469.
>>
>> I didn't say this.
>>
>
> Then how is 469 related?  True they both concern NSS but they are
> different failures which may have different causes.  The NSS issue
> reported in relation to the plugin is some kind of loading error,
> whereas the other occurs during certificate creation.
>
>>> Also, the output looks like two
>>> separate threads throwing exceptions.
>>>
>>>> with security.provider.9 commented out, I see the stacktrace in [2].
>>>> closing
>>>> the page with the applet lets the icedteanp-appletviewer-to-plugin
>>>> process
>>>> sleep.
>>>
>>> Looks like the same as the first one, but the other thread no longer
>>> crashes due to the NSS issue.
>>> I suspect there are two bugs here.  What makes you think the plugin
>>> crash is related to NSS?
>>
>> the ssl test failures in the jtreg testsuite are related to enabling NSS.
>>
>
> They are, but completely different failures and not relevant to this
> plugin issue.
>
> The NSS error here is:
>
>>>> Caused by: java.io.IOException: An incompatible version of NSS is already
>>>> loaded, 3.7 or later required
>>>>         at sun.security.pkcs11.Secmod.isInitialized(Secmod.java:130)
>>>>         at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:168)
>>>>         ... 37 more
>
> which suggests some form of loading issue in the plugin.
>
>>> The stack trace shows a parsing error:
>>>
>>> java.lang.ArrayIndexOutOfBoundsException: 5
>>>         at
>>> sun.applet.PluginProxyInfoRequest.parseReturn(PluginProxyInfoRequest.java:65)
>>>
>>>>
>>>> with security.provider.9 commented out and the nss.cfg file missing (that
>>>> is
>>>> the default when configuring without NSS, and running on a system having
>>>> NSS) you see the stacktrace as in [2], but the
>>>> icedteanp-appletviewer-to-plugin process now uses 100% cpu and doesn't
>>>> terminate even after closing the page with the applet.
>>>>
>>>> As a minimum patch, we should always install the nss.cfg file, or revert
>>>> the
>>>> (upstream?) NSS patch when not configuring with --enable-nss.
>>>
>>> We can always install nss.cfg.  It really makes no difference if the
>>> provider line is not added.
>>
>> I'm applying a patch to the trunk, setting the libdir in nss.cfg to the
>> system libdir when configuring without --enable-nss. It should do the right
>> thing, but plesae check on Fedora that it gets the lib/lib64 right.
>>
>
> This is the wrong thing to do.  I'd suggest the following instead:
>
> * Always check for NSS but only fail if it's not found and ENABLE_NSS is set:

No, for me this looks wrong. You claim that the whole nss enablement is only in 
effect if the additional provider is enabled in java.policy. Based on this 
reasoning the installation of the nss.cfg file is the right thing to do, so that 
the nss stuff can be enabled locally by editing the config files. java.policy 
should be patched as well for configurations where nss cannot be found, with the 
nss provider commented out and a comment that the nss.cfg may need editing as 
well, but better other commenting should be added to this file as well.

   Matthias