On 02/09/2013 18:45, Nick Williams wrote:
:
I didn't decide to ignore the security concerns, I just don't see any security
concerns. As has been /clearly/ established in the last three months,
frameworks have been using getCallerClass for years, if not a decade. It has
never caused a security problem. Ever. If I'm wrong, please point out to me a
specific vulnerability that this has led to.
I am not allowed to discuss any details about vulnerabilities here.
However, as a general point then caller sensitive methods have been
highly problematic in the JDK.
As regards frameworks using sun.reflect.Reflection.getCallerClass
directly then it's as I said previously, they are probably not run with
a security manager very often (at least not unless the policy is
configured to allow direct access to sun.*).
I don't have the ability to go back and start from the beginning on something
that I had the understanding was generally agreed upon before I started.
You've done good work and no one is suggesting you throw it again.
However I don't recall any agreement on a solution, rather the
discussion mostly fizzled out. In particular I do not recall any
discussions about changing the goals of JEP 176 and make @CS a public
API. Whatever about @CS methods being a bad there is also the issue of
annotations changing runtime behavior.
I see Mandy has restarted the discussion on use-cases (thank you Mandy)
and working through these and addressing a subset initially might be
good way to move this forward. More so as this is your first
patch/contribution to OpenJDK - a first patch does not have to solve
world peace, starting out with smaller changes is good.
:
I'm not voicing any objection to any kind of security/permissions checks in
these methods. Before I can pass judgement one way or another, I'd want to know
1) specifically what type of permissions check you are looking for, and 2) what
you're looking to achieve with said permissions check.
I would say this is TBD and start by asking the question as to whether
there are concerns about leaking reference to Class objects that
untrusted code wouldn't normally be able to get a reference to. Tom
brings up the cost of the permission check and also whether any API
should be tied to class loader. There are clearly discussion points here
that could potentially influence the API.
-Alan.
