db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <da...@vancouvering.com>
Subject Re: Q: Should Derby 10.3 be Derby 11?
Date Tue, 20 Feb 2007 22:17:25 GMT
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...


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.

View raw message