@jhenstridge Github Actions documentation confirms a job is run on the same VM: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/core-concepts-for-github-actions#step The documentation states the shared context is the workspace on the filesystem (mounted for containers). Each action runs in its own code. I'm hoping this code is isolated from other actions where the workspace is the only shared context. What is unclear is if each step is run on a fresh execution context. Each action can certainly require its own container, which in theory should give it an isolated context. Regardless of an action requesting a container, I hope that each action runs in an isolate execution context. If not, your vulerabilities are valid. If Github Actions share execution context, that was a trade-off of security for speed and simplicity - pull requests from forks are simply doomed. I'm not sure if you're suggesting a script could modify a workflow yaml file. Usually in CI systems, the workflow file is read and stored in memory prior to executing anything. Modifying the file would do nothing. There is certainly an issue with an `run` command where it would be next to impossible to predict where `run` code could live in a repo. That's an issue now and in any CI environment that allows scripts to be run. Secrets couldn't be shared with `run`. If execution contexts are isolated between actions, I don't see how there would be an execution level vulnerability. A run command could modify the file system, but actions shouldn't use input from the file system - only inputs from `with`.
... View more
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