Closed Zabuzard closed 7 months ago
Naturally blocked by #59
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
Still relevant and one of the main targets that should be done in the first Migration milestone.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label, comment or add the valid label or this will be closed in 5 days.
how do I implement this? last time I made a message command I was yelled at
My 2 cents:
Vast majority of jshell usages in our server are short and not multi-line. So I would say we should have a slash command as well. For the multi-line usages, go with the message-id pattern u introduced with /tag for now.
And once ready for usage: context-commands maybe (right click > execute in jshell).
not making this until we have context menus
blocked by #382
I'm mostly concerned with the security aspect of it. It's critical to have jshell instance properly sandboxed, which is not trivial, especially if we want to keep all the functionality intact. And to be honest, because of the huge impact it can create, I'm not even sure if I would be comfortable reviewing it.
So I would recommend first addressing security aspect, after we agree on the strategy we can move to the implementation details.
Paging @I-Al-Istannen, since he co-authored current jshell bot. Istannen already shared some issues, worries and design ideas on the server that are valuable addition to this issue:
For a sandbox, we can go either containers or microVMs. MicroVMs have some security benefits which would make them preferable for a sandboxed environment, but I'm not familiar with that tech (for e.g. firecracker/kata). Big Virtelization on container sandboxes - "docker as a sandbox for untrusted code".
Since we already use docker in our stack, do we agree that we probably want:
a docker container, so we have an isolated environment, by default we get
harden the docker container, to create a sandbox for untrusted code
each user gets a new container
run jshell process as non-privildeged user inside the container
I'm mostly concerned with the security aspect of it. It's critical to have jshell instance properly sandboxed, which is not trivial, especially if we want to keep all the functionality intact. And to be honest, because of the huge impact it can create, I'm not even sure if I would be comfortable reviewing it.
So I would recommend first addressing security aspect, after we agree on the strategy we can move to the implementation details.
Paging @I-Al-Istannen, since he co-authored current jshell bot. Istannen already shared some issues, worries and design ideas on the server that are valuable addition to this issue:
can't access two out of those links
someone remind me to implement this during the autumn break in germany, nrw
btw the same thing has been done before but for C++ https://github.com/Eelis/geordi
no one reminded me :angwy: will pick up the work now that we have context commands
This first completion wasn't good enough, and so JShell was never realed enabled in the bot.
We may want to migrate the JShell bot. It is actually another repo in this organization, see Together-Java/JShellBot.
For reference, this is how it works as of today:
!jshell <message>
by Jshell bot for JShell support (executing Java code)This bot has tight security restrictions as otherwise its easy for an user to escape the Java sandbox and access the actual system the bot is running on, which would be fatal. Also, the command should not be able to break the rest of the bot (its other commands).