Rick Hillegas wrote:
Unfortunately, this change has proved painful to some users. See, for
instance, DERBY-3086 and the ongoing discussion on DERBY-3083.
DERBY-3086 is simply a bug, inherently it doesn't make the default
installation of a security manager a bad idea. It's just like any other
bug in a new feature, typically such a bug would not indicate the
feature should be removed, just that the bug should be fixed. It's one
of the benefits of open source, users test features in
configurations/ways the implementor never thought of or didn't test.
DERBY-3083 is more interesting, I haven't looked at how good a job maven
does of renaming jars, does it modify the meta-data in the manifest for
the jar files it renames? If not then there is a lot more broken than
just the security manager when the jars have been mavenized, e.g. does
this work?
java -jar derbyrun-10.3.1.4.jar ij
I think having Derby being secure out of the box is a good idea, and the
default policy that we have means that it will be transparent to most users.
Also note these two:
The Apache Way: "security as a mandatory feature" [1]
Derby charter: "Derby technology provides secure data management
appropriate to environment the engine is executing in." [2]
[1] http://www.apache.org/foundation/how-it-works.html#management
[2] http://db.apache.org/derby/derby_charter.html#Secure
Dan.
