[email protected] wrote:
Installing a new version should always be backward compatible and not
break anything in existing applications. If things don't work this way,
it's bound to be (unncessarily) disruptive to some, and especially those
less sophisticated and less able to figure out and fix problems. I see
no reason why anyone who wishes to utilize the new capabilities would
have any problem with setting the new property when they are ready to do
so. Security is obviously important, especially for networked
applications. I think it's also important not to do anything that
interferes with embedded applications designed to require ZERO
administration.
+1
I think that new features that rick is proposing are valuable to some
set of Derby users, and welcome their inclusion in Derby. Having one
flag to enable a set of secure oriented features also seems reasonable
as long as users can still pick and choose if they don't want the
complete set. I don't think
they should be made the default in the current release or a future release.
I believe zero admin upgrade/backward compatibility has been a great
feature for Derby so far and we should do whatever we can to not break
it going forward. It seems like applications that need this feature set
can set the appropriate flag going forward and then do the work to
properly configure authentication and authorization, ssl encryption
passwords, and other server administration. Since there is extra work
necessary to use these features it seems reasonable to put to work on
these applications to set the flag rather than put the work on the
zero-admin applications that do not need these features.
By default Derby should be zero admin and thus default to not requiring
this extra administration.
------------------------------------------------------------------------
*From: *"Rick Hillegas" <[email protected]>
*To: *"Derby Discussion" <[email protected]>
*Sent: *Monday, September 19, 2011 12:39:07 PM
*Subject: *Derby secure by default
The Derby developers are considering introducing a single master
security property. Turning this property on will enable most Derby
security mechanisms:
1) Authentication - Will be on, requiring username/password credentials
at connection time. Derby will supply a default authentication mechanism.
2) SQL authorization - Will be on, hiding a user's data from other
people. In addition, Derby will support more SQL Standard protections
for Java routines.
3) File permissions - Will be tightened as described by DERBY-5363.
4) PUBLIC -This keyword will not be allowed as a user name.
5) SSL/TLS encryption - Will shield client/server traffic.
6) Server administration - Will require credentials.
When the property is off, Derby will behave as it does today:
Authentication, authorization, and network encryption will be off, file
permissions will inherit defaults from the account which runs the VM,
PUBLIC will be a legal user name, and server administration won't need
credentials.
This new master property will make it easier to configure a more secure
application. We want to introduce the property in an upcoming 10.x
release, where it will default to being off. That means that it won't
cause compatibility problems.
Later on, we might change the default for this property so that it would
normally be turned on. This would make Derby more secure out of the box
at the cost of breaking existing applications. Many applications would
need to explicitly turn the property off in order to run as they did
previously. Release notes would document this behavioral change and we
would bump the major release id from 10 to 11 in order to call attention
to the change.
We would like your feedback on this trade-off between security out of
the box versus disruption. Should this extra security be enabled by default?
Thanks,
-Rick
