db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject Re: [jira] Commented: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers
Date Wed, 23 Aug 2006 21:21:48 GMT
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.


View raw message