Re: Groovy sandboxing

On 8/10/26 13:17, Paul King wrote:
> I would really like to explore this further at some point but I don't
> think I will have cycles before 6 GA. Jochen, what about adding a
> summary of your analysis to the threat model to justify why we
> consider sandboxing today as something outside the language?
> 
> AI suggestion of what a summary could look like:
> 
> Why not sandbox inside the language? The most complete in-language
> mechanism available to Groovy would be to interpose on the
> invokedynamic bootstrap, through which method calls, property gets and
> extended casts are linked. That would carry a long way, and Groovy 6's
> consolidation onto a single dispatch path makes it more practical than
> it once was. It does not reach a guarantee. Statically compiled code
> emits direct invocations and never reaches the bootstrap; AST
> transformations can emit bytecode that does the same; library code not
> written in Groovy is unaffected; code can spawn a further Groovy
> compilation through a classloader; precompiled statically-compiled
> dependencies were fixed at their own compile time; and @Grab can
> introduce arbitrary artefacts. Closing any one of these does not close
> the category, which is why this model treats isolation as belonging
> outside the language rather than inside it.
> 
> That doesn't really move us forward but sets the scene for if/when we
> do? Thoughts?
In the meantime I was thinking a bit more about this... and we could in 
theory make changes to the static compiler to produce invokedynamic 
callsites using ConstantCallsite. Then you can still inspect the 
receiver class and method name. I would not make this a default though, 
but in theory we could do that. We could use the same intercept logic 
also for the invokedynamic sites. Which means not inspecting in the 
selector, but in the first bootstrap itself. That way would have a 
unified optional mechanism. But some drawbacks stay of course: no 
control over library code, no control over precompiled Groovy code using 
static compillation, compilation spawned through the class loader, usage 
of @Grab.

So for a text about why no sandbox inside the language I would 
concentrate on things we cannot control properly or not at all.

bye Jochen