db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: making Derby secure by default
Date Fri, 16 Sep 2011 16:06:59 GMT
On 9/16/2011 5:59 AM, Rick Hillegas wrote:
> I believe the benefits of a secure-by-default product are important 
> enough to justify a backwardly incompatible release and therefore to 
> bump the major release id from 10 to 11. I believe that Derby's 
> current security story is unsustainable.
I believe an ultimate switch and bump to 11 might be doable with the 
global property to revert to to the prior behavior but I don't  entirely 
understand what the new default will require users to do.  I'd like to 
understand that clearly and have the switch with the reversed default in 
place for a while for users to work with before we flip the switch on 
the default and bump the major version. I think it is really important 
that we are sure that the needed user actions with the option on are 
well documented and proven in the field before the default is changed.

> If the whole community can't move to a secure-by-default product, I am 
> worried that Derby development may fork. Those of us who are 
> interested in a secure-by-default configuration will put our effort 
> behind that profile and those who are interested in the old 
> configuration will focus on the current profile. It may be possible to 
> limit the fork to personal environments and automated tests, but I 
> confess, I don't understand how this would play out. Before launching 
> into that discussion, I would like to ask if the community could 
> support a secure-by-default 11.0 trunk sometime after 10.9 in the 
> interests of avoiding a development fork.
I certainly hope a fork won't be necessary. Worst case there could be an 
alternate build with the default switched if some people what to 
distribute the jars with the option flipped if some are more eager to do 


View raw message