Assuming you're not running Derby as an embedded server ;)
It would be great to have some backward compatibilty when running Derby embedded "local" (no server mode), at a minimum... On 2/20/07, David Van Couvering <[EMAIL PROTECTED]> wrote:
I would like to suggest we include the user community on this discussion. It is the users who are most impacted by decisions around security and compatibility. Making the call that secure-by-default trumps frictionless upgrade really needs to be done with their input and overall approval. For example, if most people are using Derby embedded, then secure-by-default in terms of authentication seems to me very low priority. If I were a using Derby in embedded mode, and I were asked which was more important, backward compatibility or secure by default, I would definitely pick compatibility... David Rick Hillegas wrote: > Thanks for raising this issue, Bernt. Here's my $.02: > > Making Derby secure-by-default is a high priority for many people on > this list. Since we're moving from wide-open, unsecure default behavior, > we have a lot of work to do. I expect we'll be making significant > security improvements for at least the next two feature releases. Once > we start advertising Derby as a secure database, I think we're committed > to closing security holes as they come up. I agree that we're changing > the network server disruptively. If this kind of change makes us bump to > a major release number, then I think we face the possibility that our > next several feature releases will all be major revisions. > > There is an unhappy tension between frictionless-upgrade and > security-by-default. I don't think the proposed compatibility rules > address that tension: > http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe > > For instance, the third bullet under "JVM Support and Version > Interoperability" makes cross-rev network connections negotiate down to > the lower rev of the protocol even if the lower rev is less secure. That > seems wrong to me. Before voting on these guidelines, I think they > should be revised so that security-by-default trumps frictionless-upgrade. > > Regards, > -Rick > > Bernt M. Johnsen wrote: >> Hi, >> >> I raise this question because it has now been introduced functionality >> that will make Derby 10.3 not entirely compatible with 10.2. >> >> It might seem innocent, but I think it deserves some discussion. >> >> With the "secure by default" functionality, Rick H. has committed a >> patch which requires me in my environment to start using the new >> -unsecure option when a started a network server. >> >> Consider the follwing quotes from two ongoing issues which describes >> incompatible behaviour: >> >> http://issues.apache.org/jira/browse/DERBY-2196 : >> >>> New Default Behavior - By default, the network server now comes up >>> with a Basic security policy. The customer may want to edit this >>> policy, using the demo/templates/server.policy template. Among other >>> side-effects, this may affect the running of customer-written >>> procedures and functions as well as other parts of the application >>> which run in the same VM with the engine. The customer may need to >>> instrument her code to run under a SecurityManager or she may need >>> to consider running with the security-disabling -unsecure option. >>> >> >> http://issues.apache.org/jira/browse/DERBY-2264 : >> >>> DBA Limits - The application may need to be changed to account for >>> the fact that only the Database Owner can shutdown, encrypt, and >>> upgrade a database. >>> >> >> So, the question is then: Is this a Derby 10 release, or should it >> really be Derby 11? >> >> Myself, I have no strong feelings, but wanted to raise the discussion. >> >> > >
