EVALUATION
Solaris softtoken team is hesitant about changing the return value, thus SunPKCS11 provider would have to make necessary adjustments.
Although Solaris softtoken impl can still perform some crypto operations, e.g. RSA keypair generations, existing SunPKCS11 provider impl has dependency on token be present and would generally not able to function. Given the rarity of such accounts, the fix is to disable SunPKCS11 provider when keystore is unaccessible.
|
|
|
EVALUATION
As Yu-ching Peng stated, the test account has a problem. Given the investigation she and I have done, it is clear that the test user does not have access to it's home directory and the system is operating as expected..
Without access to the home directory, softtoken is not operating at full functionality, it can still provide crypto services, but not perform token object support. Given this is a conformance test, it is within spec in this case to report the provider as not properly functioning..
|
|
|
EVALUATION
Re-assigning it to solaris softtoken category since it's agreed that the root cause is due to an inconsistency with PKCS#11 spec.
Also update the synopsis accordingly.
|
|
|
EVALUATION
I can only reproduce the problem with a given test account.
After further troubleshooting, it appears that Sun softtoken impl does not fully work when running under that particular account.
For example, if you run the following command line:
--------------------------------------------------------------------------
$ cryptoadm list -v provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
Number of slots: 1
Slot #1
Description: Sun Crypto Softtoken
Manufacturer: Sun Microsystems, Inc.
PKCS#11 Version: 2.11
Hardware Version: 0.0
Firmware Version: 0.0
Token Present: False
Slot Flags:
/usr/lib/security/$ISA/pkcs11_softtoken.so: failed to retrieve the mechanism list.
--------------------------------------------------------------------------
I tried to inspect the default keystore used by Sun softtoken impl with pktool but the "<user home>/.sunw/pkcs11_softtoken" directory is not there. Nor do I get expected behavior when running "pktool setpin" command.
Thus, this suggests that the problem is in the account setup and not Sun's PKCS#11 provider.
Changing the status to Incomplete/Other until further confirmation from the submitter.
|
|
|
EVALUATION
It's unclear why these tests only fail when running in Java Plugin. Thus, please provide detailed information on how these tests are executed.
Again, marking this w/ "incomplete - need more info".
|
|
|
EVALUATION
I don't observe any JCK test failure using both the official jdk6 b105 and my own jdk7 builds on Solaris 10. The JCK tests are executed as:
-----------------
/java/re/jdk/6.0/promoted/fcs/b105/binaries/solaris-sparc/bin/java -showversion -classpath /java/re/jck/6a/nightly/qac/b06-2007-02-08/binaries/JCK-runtime-6a/classes:/java/re/jck/6a/nightly/qac/b06-2007-02-08/binaries/JCK-runtime-6a/lib/javatest.jar javasoft.sqe.tests.api.java.security.AuthProvider.loginTests
-----------------
The output looks fine too. Sample messages:
Provider XMLDSig: Passed. Not AuthProvider. Skiped.
Provider SUN: Passed. Not AuthProvider. Skiped.
...
Provider SunSASL: Passed. Not AuthProvider. Skiped.
Provider SunPKCS11-Solaris: Passed. OKAY
Provider SunRsaSign: Passed. Not AuthProvider. Skiped.
Provider SunJGSS: Passed. Not AuthProvider. Skiped.
So, I am marking this bug "incomplete" for now so that submitter can verify if this bug can still be reproduced on his end.
|
|
|
Java