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.
I think this discussion really needs to be grounded in some facts:
1) about what backwards compatibility issues there are with the
various changes
2) a good definition of "secure-by-default".
A wiki page with the proposed backwards compatibility issues listed
together and with definition(s) of secure-by-default would be good.
Since Rick seems to be proposing most of the backwards compatibility
issues he seems like a good candidate to write the initial version of
the page. :-) It could be just the collection of tables from the various
functional specs.
I don't think one can take a stand of compatibility is always better
than security or vice-versa, it's a case by case basis.
Dan.
