Skip to content

merge queue: checking #1786 on main (caba8c3) - #1788

Closed
mergify[bot] wants to merge 3 commits into
mainfrom
mergify/merge-queue/c2957e92b5
Closed

merge queue: checking #1786 on main (caba8c3)#1788
mergify[bot] wants to merge 3 commits into
mainfrom
mergify/merge-queue/c2957e92b5

Conversation

@mergify

@mergify mergify Bot commented Aug 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🎉 This pull request has been checked successfully and will be merged soon. 🎉

#1786 is queued for merge on branch main (caba8c3).

This pull request has been created by Mergify to check the mergeability of #1786.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

Required conditions to stay in the queue:

---
checking_base_sha: caba8c38e4af172f765b1d4d4ceabdf981918e7c
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 1786
    scopes: []
scopes: []
...

sileht and others added 3 commits August 25, 2026 12:37
@sileht
fix(ci): reject a checking_base_sha that is not a git object name
1405948 
`ci git-refs` took the merge-queue `checking_base_sha` verbatim out of
the merge-queue draft pull request body and emitted it as `base`.
`queue_metadata::extract_from_event` admits a body on the title prefix
`merge queue: ` and nothing else, so whoever opens the pull request
writes that value, fork PRs included.

`base` then leaves the CLI through several sinks that read a leading
`-` as an option: `$GITHUB_OUTPUT` and the `--format=shell` eval hand
it to the caller's workflow, `ci scopes` puts it in git invocations,
and both commands echo it to stderr, which GitHub Actions also scans
for `::` workflow commands. The reporter's proof run put
`checking_base_sha: --output=/home/runner/.gitconfig` in a fork PR body
and truncated that file inside the job.

Require a full hex object name, 40 digits or 64, before the value can
become a base. Abbreviations are out on purpose:
`scopes_detect::changed_files::is_sha` routes only full SHAs as
revisions, so a short one is fetched as a branch name and fails the
run. Nothing honest is lost, the engine types the field
`github_types.SHAType` and writes a full SHA.

The gate is on the pull request body alone, not on the git note that
carries the same field. That asymmetry is deliberate: the note comes
from the engine over a push to `origin`, and a note the check rejected
would fall through to the body path, handing the untrusted payload the
precedence the note is meant to hold, silently, since
`real_notes_reader` has no `Output` to warn through.

A rejected value is not metadata, so it falls through to the pull
request's own base with a warning, the shape already used when the key
is missing. The warning renders the value escaped and cut to a bounded
length, so it can neither start a workflow command of its own nor fill
the log.

Reported as HackerOne #3965784, closed Informative: the blast radius is
the ephemeral runner the pull request itself triggered.

Fixes MRGFY-8845

Change-Id: Ie24ad032ac9c96b1231e76bc30ece50cd905d8d2
@sileht
refactor(ci): share one $GITHUB_OUTPUT heredoc writer
b4f4bf5 
`ci queue-info` and `ci scopes` each carried their own copy of the
"open $GITHUB_OUTPUT, draw a random ghadelimiter_ suffix, write the
heredoc" sequence, including a byte-for-byte duplicate of
`random_delimiter_suffix`. `ci git-refs` needs the same thing next,
which would have made three.

Move it to a `github_output` module that takes the `(name, value)`
pairs and does the rest, so a call site cannot pick the bare
`name=value` form by accident: the heredoc is the only form the module
emits, and its delimiter comes fresh from the OS RNG per output.

The name half of the pair is `&'static str` rather than `&str`. A
newline in a name, or an `=` ahead of the `<<`, lets the runner read
the block as something else, and the type keeps a name derived from a
payload out by construction.

The block is assembled and written once. Three `writeln!` calls on an
unbuffered `File` are several `write_all` syscalls each, and a
sequence cut in the middle leaves an unterminated heredoc, which fails
the step outright rather than losing a line.

`junit_process` keeps its own bare-form writer; the module says why.

What is written does not change. GitHub parses both forms into the
same output value, and both migrated call sites already wrote the
heredoc. Each now builds its payload before the `$GITHUB_OUTPUT` check
rather than after, so off a GitHub Actions runner one small string is
built and dropped.

Fixes MRGFY-8845

Change-Id: Ie32fc586e5e6313a5f46f63b6da728ddf867f850
@mergify
Merge of #1786
f884050
@mergify
mergify Bot deployed to Mergify Merge Protections August 25, 2026 19:39 Active
@mergify
mergify Bot deployed to func-tests-live August 25, 2026 19:39 Active
@mergify mergify Bot mentioned this pull request Aug 25, 2026
Merged
@mergify mergify Bot closed this Aug 25, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/c2957e92b5 branch August 25, 2026 19:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@sileht