> You have to consider the software in the context it is intended to be
> used.
Thank you for clarifying and illustrating those notions. We are in agreement
about JEXL intended usage and where the responsibility lies wrt security
choices.
But even in its usage context, with authenticated u
On 31/10/2022 14:03, Henri Biestro wrote:
Let's restrict this discussion to the case of 'authenticated and authorised
users' of an 'enterprise platform'.
When we talk about 'unsafe input' vs 'safe input', I'm still confused about
what this actually entails. Let's assume we want those users to
Let's restrict this discussion to the case of 'authenticated and authorised
users' of an 'enterprise platform'.
When we talk about 'unsafe input' vs 'safe input', I'm still confused about
what this actually entails. Let's assume we want those users to enter a (JEXL)
expression to express their
On 26/10/2022 08:58, Henri Biestro wrote:
Fair points, thank you. They seem to lead into the point of view that JEXL (or
any scripting solution?) should not expose any feature that could be considered
security-related avoiding the CVE potential turmoils alltogether. Trusted
sanitised input is
Fair points, thank you. They seem to lead into the point of view that JEXL (or
any scripting solution?) should not expose any feature that could be considered
security-related avoiding the CVE potential turmoils alltogether. Trusted
sanitised input is expected and required so this is a moot d
On 24/10/2022 17:02, Henri Biestro (Apache) wrote:
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 res
