BUGFIX-66: Algorithmic Puzzles in Go
173 views
Skip to first unread message
BUGFIX 66
Nov 11, 2022, 1:47:17 PM11/11/22
to golang-nuts
Still under construction: https://BUGFIX-66.com
Site is intended to be like the book Hacker's Delight, but as a game.
Site is intended to be like the book Hacker's Delight, but as a game.
Or like professional programming, where you're mostly trying to understand/modify other people's code.
Or like programming in a post-GPT3 world where you're checking/fixing a transformer language model's plagiarized/regurgitated code. Our dystopian future.
The site builds and runs your code. If your code doesn't compile or doesn't compute the correct function, the code is rejected.
Each puzzle is a little program. Look at the example here:
https://bugfix-66.com/contribute
The code you edit on the website is under "// EDIT". Any code you put into the web form is compiled and run on the server.
The site builds and runs your code. If your code doesn't compile or doesn't compute the correct function, the code is rejected.
Each puzzle is a little program. Look at the example here:
https://bugfix-66.com/contribute
The code you edit on the website is under "// EDIT". Any code you put into the web form is compiled and run on the server.
I'm relying on the fact that the Go language allows imports only at the start of the program text (immediately following the package statement).
package xxx
import yyy
<... testing functions, etc., that I control ...>
<code from website inserted here, so it can't import>
Basically, the user can never write an import statement, and that's enough.
Go doesn't allow inline assembly, so direct syscalls are impossible. All memory accesses are bounds checked.
The code is built and executed with resource limits on memory and CPU time.
If you can think of a way the server could be compromised, I'm VERY interested to hear it. Thank you.
package xxx
import yyy
<... testing functions, etc., that I control ...>
<code from website inserted here, so it can't import>
Basically, the user can never write an import statement, and that's enough.
Go doesn't allow inline assembly, so direct syscalls are impossible. All memory accesses are bounds checked.
The code is built and executed with resource limits on memory and CPU time.
If you can think of a way the server could be compromised, I'm VERY interested to hear it. Thank you.
Matt Harden
Nov 13, 2022, 3:38:50 PM11/13/22
to BUGFIX 66, golang-nuts
Sounds fun!
Go doesn't prevent race conditions and those can result in undefined behavior, so I don't think you're safe just restricting imports and limiting CPU and memory. You need to run code in a sandbox of some sort. I would look at what the Go playground does.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fd676e28-3639-4fc8-a7b4-3288e08fdd3en%40googlegroups.com.
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages