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

Reply via email to