On May 23, 2007, at 7:56 PM, Marc Prud'hommeaux wrote:
I asked a number of times for a security audit to be made of the
security implications of JPA and it was never taken up. Most of
the vendors make extensive use of privileged operations including
getting system properties, reflection, and class loader operations
and IMHO not enough attention was paid to getting it right.
That includes us. To be perfectly frank, in all the years of Kodo
and OpenJPA, it has simply never been an issue.
Which doesn't mean that we shouldn't endeavor to fix the problems
and do it all the right way, security-wise. I'm just pointing out
that the demand for well-behaved security-sensitive applications is
not as high as one might expect.
Implementing java2 security can create very complex code structures
that are difficult for people to read, debug, maintain, and improve.
If someone wants to implement this (and I would say that's a huge
if), I would like to see the effort focused on making sure the code
is still readable.
I really like kevin's suggestion to just pop in a wrapper if you care
about Java2 security. Or maybe we can create a doPriv subclass of
EMF, for those that care (of course open out calls like lifecycle
callbacks would need an exit doPriv).
In my experience, I've never seen someone use Java2 security in
production.
-dain
