---
title: "MGS3027: queue run untrusted"
description: magus queue apply refused to read a validation run that the base branch's own queue workflow did not start, since such a run uploads whatever its author wrote.
tags: [MGS3027, merge queue, magus queue, github, workflow_run, security]
---

# MGS3027: queue run untrusted

`magus queue apply` was pointed at a run (`run:<owner>/<name>/runs/<id>`) and
read what started it before downloading anything. The run was not the
`--workflow` definition started by a push or a dispatch on `--base` of the
repository itself, so apply read nothing it uploaded.

```text
[MGS3027] run acme/widgets/runs/7 is not .github/workflows/queue.yaml run by
acme/widgets's own main: "pull_request" started it, and that event runs a
definition a change supplied; apply reads nothing it uploaded
```

## Why

Apply holds the write credential and merges what validation's artifacts say is
green. Its trust in those artifacts rests on who wrote them: the plan and the
verdicts must come from the base branch's own copy of the queue workflow.

A pull request event runs the pull request's own copy of the workflow file,
and a fork's run reaches this repository's `workflow_run` followers too. On
GitHub, `workflow_run` matches workflows by name, so any file named like the
queue's triggers it. Such a run can upload a `mergequeue-plan` and
`mergequeue-verdict-<id>` artifacts of its own choosing. Candidates are built
with a fixed identity and date, so a forged verdict can name the very commit
apply rebuilds, and apply would post `success` on a change nobody validated.

The run is refused when any of these holds:

- the event that started it runs a definition a change supplied (on GitHub,
  anything but `push` and `workflow_dispatch`);
- it ran a commit of another repository than its own (a fork);
- it ran on another branch than `--base`;
- it ran another definition than `--workflow`.

## Resolution

Point apply at a run of the base's own queue workflow. In this repository's
setup, `queue-apply.yaml` follows only such a run, and answers a pull
request's run by dispatching `queue.yaml` on main instead. If a run you expected
to be followed was refused, check the `--base` and `--workflow` the workflow
passes, and that the run was started by a push to the base or a dispatch on it.

See the [merge queue's trust model](../../../concepts/merge-queue.md#trust-model).