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
Rick, I’d vote for secure by default in v.11. Thanks
On Mon, Sep 19, 2011 at 6:39 PM, Rick Hillegas rick.hille...@oracle.com wrote:
The Derby developers are considering introducing a single master security
property. Turning this property on will enable most Derby security
mechanisms:
1)
Off by default for the release coming out. On by default if you want at the
next major release.
-Original Message-
From: Rick Hillegas [mailto:rick.hille...@oracle.com]
Sent: Monday, September 19, 2011 12:39 PM
To: Derby Discussion
Subject: Derby secure by default
The Derby developers
nice to contact every one,This is my first time to mail in english,please
forgive me.
#1.It seems that when procedure in a class was loaded, drop and reloaded, the
changes of JAR file havn't take effected!
eg script:
drop PROCEDURE test;
call sqlj.remove_jar('admin.creaateClient', 0);
I am not sure how it applies to all of these points, but I am wondering
if secure by default should be implemented on a per database basis
rather than a system level basis? It seems wierd that security could
change based on how the next embedded startup set a flag.
What about having the
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 especial ly those less
sophisticated and less able to figure out and fix problems. I see no
Hi Mike,
Some comments inline...
On 9/19/11 10:38 AM, Mike Matrigali wrote:
I am not sure how it applies to all of these points, but I am
wondering if secure by default should be implemented on a per database
basis rather than a system level basis? It seems wierd that security
could
change
(perhaps this has already been discussed in the devs' mailing list, if so,
forgive my ignorance).
I'm not sure whether making the default value on will actually improve
security as a whole. If a developer hasn't given thought to security, there
are plenty of other pitfalls that may compromise an
Embedded applications have to secure their own points of entry and turning
Derby security on by default will do nothing. Unless the Java security
manager is active, everything is wide open via the reflection APIs when you
are embedded in-process with the database.
Best-guess for me would be if
Rick Hillegas wrote:
I'm also concerned about the embedded database on a USB stick. I could
argue that it is more vulnerable than the server-side database locked up
in a machine room.
Derby has one answer to this issue and that is encrypted databases. I
don't think anything other than that
Rick Hillegas wrote:
Hi Mike,
Some comments inline...
On 9/19/11 10:38 AM, Mike Matrigali wrote:
I am not sure how it applies to all of these points, but I am
wondering if secure by default should be implemented on a per database
basis rather than a system level basis? It seems wierd that
roy.mi...@comcast.net 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
On 9/19/2011 1:20 PM, José Ventura wrote:
I'm not sure whether making the default value on will actually
improve security as a whole. If a developer hasn't given thought to
security, there are plenty of other pitfalls that may compromise an
application (e.g. where should I store the
13 matches
Mail list logo
