Hi Francois, Thanks for taking this task on.
Francois Orsini (JIRA) wrote:
<snip>....You're right that there is no longer an issue with a DERBY-528 and a
10.2 client connecting to a 10.1 derby server, I reverted back to having
CLEAR_TEXT_PASSWORD being the default SECMEC to use on client datasource (if
EUSRIDPWD cannot be selected because of the current JVM restricting the use of
256-bit DH keys).
Without DERBY-1517, a DRDA protocol exception will be raised if an invalid
securityMechanism is specified for the server the client connects to - This was
a fairly non-blocking and non-visible issue since all pre-DERBY-528 DRDA secmec
were supported by pretty much all existing Derby DRDA servers out there.
Eventhough DERBY-926 needs to be addressed, DERBY-1517 will allow a new DRDA
secmec (like USRSSBPWD) to be used as a fall-back default when EUSRIDPWD cannot
be used,
It seems to me we need some amount of negotiation between the server and
client on the security mechanism to use. (correct?)
E.g. For having secmec 8 to be used by default by the 10.2 client, the
old server will not recognize this and will currently send a list of
supported secmecs (in the wrong format -derby926). Changes will be
needed in the client to parse these values and then choose one of the
secmec's that is valid for the server. Were you planning on making
these changes so secmec 8 can be used as the fallback default or did you
have some other approach in mind. Are you targeting this for 10.2.
I also noticed a problem in the client, using the default to secmec 9.
I think it is not sufficient to only check if client jvm can support
eusridpwd as is done currently (derby-962) but we need to verify if the
server can support the particular secmec. At the very least, to avoid
regressing, we should revert back to secmec 3. I'll open a jira to fix
this. I'll link all these related jiras (derby-1675,derby-926)
Also, the sooner we fix DERBY-926, the better it is for no longer carrying
servers that are returning the list of supported secmec's incorrectly.
+1.
Thanks,
Sunitha.
