Open ColdHeat opened 4 months ago
Likely, if the healthcheck file ends in .jinja
We can render it to the same folder with the extension removed and then execute the script.
So for example:
healthcheck: solve.py.jinja
This points to a solution script expecting jinja variables. It gets templated by ctfcli, then written to solve.py
and then executed via subprocess.
Although likely it might just make more sense to just keep it reading as argument variables...
I like the current healthcheck system, I think jinja templates is an extra degree of unneeded complexity.
It looks at some point healthchecks changed to using a --connection-info
switch. I think a better choice is to pass the information using envvars.
Stopping by to say that I agree that jinja templating for solve scripts is over the top. If anything, jinja templating for the command to invoke the solve script would be nice, so you could do something like healthcheck_command: ./solve.py HOST={{host}} PORT={{port}}
(which works nicely with pwntools args) or however your script expects it. To pass as env vars, just put them first, like any other shell command. So the expectation is this string will be passed to the shell to parse and execute.
I believe our healthcheck implemtnation is currently lacking so just writing some notes on improving it.
I believe ctfcli should treat a solve script as a kind of template. Possibly a Jinja template and populate specific variables and then run the script.
For example we could have something like:
ctfcli will render this to a temporary file and then execute it.