Community
Participate
Working Groups
Build R2.0 Eclipse fails to read the .keyring file containing CVS passwords when running on IBM JDK 1.4.0, and leaves it corrupted, as follows: java.io.IOException: SHA1PRNG SecureRandom not available at org.eclipse.core.internal.runtime.CipherInputStream.read (CipherInputStream.java:71) at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2138) at java.io.ObjectInputStream$PeekInputStream.readFully (ObjectInputStream.java:2151) at java.io.ObjectInputStream$BlockDataInputStream.readShort (ObjectInputStream.java:2622) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:729) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:254) at org.eclipse.core.internal.runtime.AuthorizationDatabase.load (AuthorizationDatabase.java:260) at org.eclipse.core.internal.runtime.AuthorizationDatabase.load (AuthorizationDatabase.java:248) at org.eclipse.core.internal.runtime.AuthorizationDatabase.<init> (AuthorizationDatabase.java:73) at org.eclipse.core.internal.runtime.InternalPlatform.loadKeyring (InternalPlatform.java:589) The code fails because there is a hard coded reference to a Sun implementation of a random number stream "SHA1PRNG" (see org.eclipse.core.internal.runtime.Cipher#nextRandom(int)) that is unavailable by default in IBM's JRE. The code should not reference a particular algorithm. A work around is to add the following line to jre/lib/security/java.security: security.provider.5=sun.security.provider.Sun
SHA1PRNG is listed as a standard algorithm name in the Java 2 SDK Security API (Appendix A). That spec states that the algorithm names in that appendix are the standard required names. Shouldn't all compliant JREs have that algorithm available? It is available in IBM JRE 1.3 and in J9. Since SHA1PRNG is the only specified algorithm name, the only alternative is to use the default constructor of SecureRandom. The only problem with using it is that we won't know what algorithm is used. This means the keyring file will probably never be portable across VMs. It might also be difficult for export control requirements which require us to specify what encryption algorithms are used in the product.
I have released a fix to the HEAD (2.1) stream. We're now using our own secure number generator based on SHA-1. This also fixes our long-standing problem that SHA1PRNG produced a different bit stream on J9, thus .keyring files were never portable between J9 and non-J9 VMs. We should consider as a 2.0.1 candidate.
I agree this should be 2.0.1.
