Hello Commons; JEXL-381 is an attempt at making JEXL's default more secure or at least less 'permeable' wrt to the application/platform/JVM/file-system/host that runs it. Based on JexlPermissions - a crude security visibility manager -, this restricts the *default* behavior of what is visible to JEXL scripts to the basics (lang, math, text, collection,...). This does prevent a future crude test of some kind leading to a CVE stating that JEXL poses a security risk since it can create processes or read the whole file-system (cf JEXL-223).
I'd like opinions on this idea - assuming it is not a bad one - and how to best expose it. Although JEXL 3.3 is compatible with JEXL 3.2, the runtime behavior might break due to these new default security restrictions. The net-cost is that current users (people actually using JEXL for its intended purpose) will have to actively decide how much permeability they need if they want to upgrade to JEXL 3.3 and retain functionality. They will probably gain at least some insight about their platform/product security. Note that the basic mitigation - being as permeable as JEXL 3.2 - costs only a line of code.. Ideas on how to best warn/expose/explain this to users and any element pertaining to this subject is welcome. :-) Thanks Henrib
