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.
