NSS configuration & plugin interaction

[Andrew John Hughes]

On 8 April 2010 23:25, Matthias Klose <doko at ubuntu.com> wrote:
> 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. j

Yes, my patch does that too; even if --enable-nss is not set, NSS is
still checked for but does not cause the build to fail.  What I guess
you want is to have a value for libdir even when NSS is not present,
so I'll add your hack as a further fallback.  As you've admitted may
not work on all distros, we should try detecting NSS properly first.

> 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.

I didn't see a patch for this in your changeset.

>
>  Matthias
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8