On 01.04.2018 19:58, MG wrote:
Hi Jochen,
I just thought about some post by another project I read some time back
(alas I can no longer remember which project exactly) which used Groovy
as its scripting language, but switched to a lesser, more restrictive
scripting option, because they needed to make the scripting more secure,
which, according to the post, could not be done using Groovy "because of
all the reflection Groovy uses". So I was wondering if changes at a
fundamental level in Groovy seem unavoidable, if it would make sense to
also keep the security aspect in mind ?
In my opinion that project is wrong, because the security manager
mechanisms provide enough protection. The problem is that rarely anyone
can use a security manager properly. Anyway... Groovy won't be able to
do any call Java cannot do in principle in this version. That is not
because of keeping security in mind, that is more because of the module
system, that enforces this
Of course you cannot be everything to everyone, even if Groovy comes
close, but if e.g. reflection usage inside a Groovy script could be
prohibited (afair that was one of the problems the post cited) within
the new, Java 9 module approach, that could conceivably make sense...
My approach does not use setAccessible anymore, which is the problematic
part when using reflection.
bye Jochen
