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
so.
Kathey
