[ http://issues.apache.org/jira/browse/DERBY-1517?page=comments#action_12422733 ] Francois Orsini commented on DERBY-1517: ----------------------------------------
I know you figured it out already Kathey - am just adding a comment here for the record. 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). So, yes as it stands right now, the current DERBY-528 do not cause impact changes for existing users of Derby whom would use a 10.2 client for instance. 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, and no longer causing the protocol exception described in 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. Thanks, > Derby Network Client to handle list of SECMEC(s) returned by > existing/released DRDA Derby Network Servers > --------------------------------------------------------------------------------------------------------- > > Key: DERBY-1517 > URL: http://issues.apache.org/jira/browse/DERBY-1517 > Project: Derby > Issue Type: Bug > Components: Network Client > Environment: The Derby network client should be made capable of > handling a list of SECMEC(s) returned by previously released DRDA Derby > network servers > Reporter: Francois Orsini > Fix For: 10.2.0.0 > > > Currently, the Derby DRDA network server does not *properly* return the list > of SECMEC(s) it can support if a client is requesting to authenticate with a > non-supported SECMEC (see JIRA-926 - > http://issues.apache.org/jira/browse/DERBY-926) > The motivation for this JIRA is to add the logic for the Derby client to be > capable of parsing the list of supported SECMEC(s) returned by previous > released Derby network servers (pre-JIRA-926 Fix) - This is necessary for > backwards compatibility with older servers - This issue has been even more > visible as Derby-528 introduces support for a new DRDA security mechanism > (Strong Password Substitute), which causes a DRDA protocol exception when > trying to authenticate with the new supported mechanism against older Derby > DRDA servers (JIRA-926 issue) > JIRA-926 has to be fixed nonetheless on the server side to properly return > the list of supported SECMEC(s) in conformance with the DRDA (DDM) specs - > This JIRA focuses on the client side to do its best and be capable of parsing > a list of SECMEC(s) returned pre-926 fix. > Ultimately, the derby network client can be made capable of parsing a list of > SECMEC(s) from pre-926 fixed (older) and post-926 fixed servers... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
