Default git commit verification to strict in v4 - #4145
Conversation
|
@buildsworth-bk - review please! |
There was a problem hiding this comment.
The warning-path issue is inline. This changes a security policy and the checkout path for every eligible job, so final approval needs a human; the intentional removal of an off mode is the key policy call to confirm.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 11121, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
About buildsworth
Model: gpt-5.6-sol with xhigh thinking.
How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.
Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. To let it approve, grant L2 approval by mentioning @buildsworth-bk (see L2 approval grant):
- L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
- L2 — Standard risk (new UI, additive API fields, refactors). Approved only with an L2 grant; otherwise comment-only.
- L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.
There was a problem hiding this comment.
No new code findings after the warning-path fix. This still sets a security policy for every eligible checkout and intentionally removes the off mode, so it needs human sign-off; the agent CI build is also currently failing.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 11194, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
6a3e6a0 to
90b3d4b
Compare
Co-authored-by: buildsworth-bk-app[bot] <265670805+buildsworth-bk-app[bot]@users.noreply.github.com>
d13cd99 to
0fd3444
Compare
There was a problem hiding this comment.
The implementation now makes strict the default and retains an explicit off escape hatch. This changes a security policy and the checkout path for every eligible job, so it still needs human sign-off; the migration documentation mismatch is inline.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 11689, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
…ication-default Default git commit verification to strict in v4
…ication-default Default git commit verification to strict in v4
…agent v4 A Docs Private copy of buildkite#3145. ## Description Document that Buildkite agent v4 uses strict Git commit verification by default and supports `off` as the explicit opt-out. ## Context - [A-1592: Consider git commit verification strict as default in v4](https://linear.app/buildkite/issue/A-1592/consider-git-commit-verification-strict-as-default-in-v4) - Companion implementation: [buildkite/agent#4145](buildkite/agent#4145) ## Changes - Add the new default and migration guidance to the agent v3-to-v4 upgrade guide. - Document `strict` and `off` as the supported v4 modes in the Git checkout and command-step references. - Update the `BUILDKITE_GIT_COMMIT_VERIFICATION` environment-variable reference. - Clarify that agent v3 does not verify commits unless configured. - Explain how v4 handles empty values from agent configuration and job checkout configuration. ## Verification - Markdownlint passes for the three changed Markdown pages. - The environment-variable content validates against its schema. - Vale reports no errors, warnings, or suggestions in the changed documentation. - `git diff --check` passes. ## Deployment These documentation changes should be published alongside the agent v4 behavior change. ## Rollback Revert this PR if the agent behavior change is reverted. ## Disclosures / Credits OpenAI Codex prepared the documentation updates under Jamie Monserrate's direction.
Description
Make Git commit verification a secure default in agent v4.
The agent now uses
strictwhengit-commit-verificationis not configured. Operators can explicitly selectoffto skip verification entirely. The supported v4 modes arestrictandoff;warn, empty values, and other unsupported CLI values are rejected.The zero value in a programmatically constructed executor configuration remains fail-closed and behaves as
strict. Verification that cannot be completed because of an infrastructure problem remains warning-only, preserving the existing availability behavior.Context
Changes
--git-commit-verificationtostrict.strictandofffrom flags, environment variables, and config files.offskip branch-tip fetching and the ancestry check entirely.strictand reject other unrecognized executor values.Design decision: explicit off mode
This PR changes both the default and the supported modes. Agent v4 enables verification by default with
strict, whileoffprovides an explicit escape hatch for operators who cannot run the verification fetch and ancestry checks.In
strictmode, a definitive branch/commit mismatch fails the job. If the check is unavailable because of an infrastructure problem, the agent warns and continues. Existing skip conditions forHEAD, tags, pull requests, custom refspecs, and builds without a branch remain unchanged.Testing
Tested that I was able to disable the verification

And when the verification is enabled, it fails properly

Deployment
This is an intentional v4 behavior change. Operators who need to disable verification must set
git-commit-verification="off"orBUILDKITE_GIT_COMMIT_VERIFICATION=off. Existingwarnor empty configurations must be changed to eitherstrictoroff. There are no data migrations.Rollback
Revert this PR to restore the previous empty default and
warnbehavior.Affiliation (optional, external contributors)
Buildkite.
Disclosures / Credits
OpenAI Codex implemented the change and tests under Jamie Monserrate's direction.