I just started looking at this issue on how to know if the jvm in which the client is running can support encrypted userid and password mechanism or not; to decide if we can upgrade the default security mechanism.
I wanted to share some thoughts I have, so I could get early feedback from the list.
Current client driver supports encrypted userid/password (EUSRIDPWD) via the use of DH key-agreement protocol - however current Open Group DRDA specifications imposes small prime and base generator values (256 bits) that prevents other JCE's (apt from ibm jce) to be used as java cryptography providers.
– org.apache.derby.client.am.EncryptionManager (EM) constructor is responsible for instantiating the appropriate Provider and the KeyPairGenerator. The Sun JCE throws java.security.InvalidAlgorithmParameterException exception when trying to use the 256bits prime.
I think we can conclude if the EM throws an exception, then the JCE doesnt support the required algorithms.
=> An exception from this constructor indicates that it is not possible to use encrypted userid/password.
The next step seems to me to decide where to put the call to new EncryptionManager(EM)
#A.Put in static initializer block in ClientBaseDataSource and store the result in a static variable. The ClientBaseDataSource seems to be place where all the url attribute values' gets and sets methods are present. Also the upgrade logic for the security mechanism is in this class.
static boolean SUPPORTS_EUSRIDPWD = false;
SUPPORTS_EUSRIDPWD = true;
#B. Another place this check could go was in the ClientDriver itself since this will be loaded in the JVM. In the static initializer of ClientDriver, new of EM can be done to check if it will go through OK. If so, a static 'protected' variable in ClientDriver can be used to store the state that the driver supports the algorithms required for encrypted userid/password.
1. Are there any issues with adding code to the static initializer block of the Client Driver. I see the following comment in ClientDriver which sounds a little scary to me.
// This may possibly hit the race-condition bug of java 1.1.
// The Configuration static clause should execute before the following line does.
if (Configuration.exceptionsOnLoadResources != null)
I can see that the Configuration static initializer needs to run before the access to the static variable Configuration.exceptionsOnLoadResources.
I'm curious and would like to look at it sometime. If someone could point me to some reference of this bug, I'd be grateful. I googled but didnt find any related to the static intializer blocks.
#C Explicitly check the jvm and decide. Not a good way for e.g. if SunJCE supports the DH with 256 bits prime some day, we would have to remember to remove this check that disables encrypted userid/password for this particular JVM.
I like #A because it seems clean. What do others think ?