db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers
Date Fri, 21 Jul 2006 18:22:14 GMT
    [ 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.


> 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:
> 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


View raw message