Putting asside secrets used to upload a mark, if you're relying on a workflow running in the student's repository to generate the mark, you've essentially built a self assessment system. Maybe it would be better having a system where the student requests that their work be marked, and some system out of their control assesses their work. You could still use Github actions to perform the assessment though, instead relying on a workflow running in a repository you control. For example, you could have a workflow starting with: steps:
- name: Check out the assessment harness
- name: Check out the student's code
ref: master # or whatever revision you want to test
path: ./under-test # where you want to put the student's work Since the workflow is in a repository you control, you can easily make use of secrets. It could even be a private repo if needed. That leaves the question of how to trigger the workflow for a particular student's work. From the look of it, "on: repository_dispatch" looks promising. This would let you trigger the workflow with a simple HTTP POST request with parameters like the repository name in the request body. As the dispatch API endpoint requires authentication, you can't easily have students call it directly. You would probably want some simple system that takes the repository as input, checks that it actually belongs to a student and then sends the appropriate trigger.
... View more
All the actions in a job are run within the same VM image, with each action altering the environment of the next to some extent. This is most obvious with the "actions/checkout" action, which makes the the contents of the repository available to subsequent actions. If an action or "run:" step could leave a process running in the background, then it could likely wait for a the new action process to be created and then snoop its "INPUT_*" environment variables for the secrets. Alternatively, if you know that the action managing the secrets will run some subprocess, you could potentially prepend a directory to $PATH so that it instead invokes a malicious version of that program that can access the secrets. So it is not enough to just check that the step invoking the action that consumes secrets has been unchanged: you need to worry about every step prior to it. And if one of those steps invokes the project's build system, it might not even be necessary to modify the workflow yaml file at all.
... View more