-
-
Concept diagram: authority can change between job admission and its physical effect. Actual execution evidence is linked in the project.
Inspiration
A denied request does not prove that queued work stopped. An export can be approved, wait in a queue, lose its owner's permission, and still write a protected file later. Checking only the next HTTP 403 misses that effect. An over-eager repair can cause the opposite error: blocking work that the service already promised to complete.
BranchCheck is for developers and reviewers changing permission-sensitive background jobs. We adapted accounting-style reconciliation: connect authority history, admitted job IDs, actual file bytes and terminal records, then compare them with an explicit policy. The application's success message is one observation, not the final verdict.
What it does
A human selects a supported permission-timing contract. BranchCheck generates finite schedules, runs a cooperative HTTP application with an external queue and worker checkpoint, and verifies actual files in a registered sink. It checks both forbidden effects and permitted work, including another user's exports, retained read access, revoke/regrant and already completed files.
The contract distinguishes current authority when an effect occurs, an unchanged authority epoch since enqueue, and authority fixed at admission. The same late export can be a violation under one contract and required behavior under another. Blocking everything is not a valid repair.
BranchCheck gives GitLab Duo reproducible policy and failure evidence. Duo changes the application; the verifier then checks the changed source under the same criteria. A human reviews the diff, CI results and physical-effect records. Results distinguish completed checks, observed violations and unverified execution.
How we built it
Python 3.13 and standard-library HTTP, JSON and unittest tools implement the runner, source/criteria binding, reconciliation and evidence viewer. GitLab Duo Developer Flow and GitLab CI/CD connect application repair to inspectable execution records.
In actual Duo session 9997458, repair 6cebe0a changed only async_application/policy.py, reading the job actor's current permission after the pre-effect checkpoint. The contract, evaluator, tests and CI were unchanged by that repair.
The before pipeline completed ten conditions with four failures. The after pipeline passed the same ten conditions. The eight discrepancy records before repair came from one known mechanism observed as four physical effects and four terminal-status discrepancies; they were not eight distinct bugs.
The current release adds native JUnit reports and a blocking CI runner. Policy violations become failures; missing, unfinished or source/criteria-invalid observations become errors. The runner preserves nonzero process and report outcomes. Pipeline 2985825048, pinned to d5a6ce0, passed all five jobs and 28 native JUnit expectations: ten temporal conditions and eighteen File Browser controls, with zero failures, errors or skips.
The File Browser job runs checksum-pinned official Linux versions 2.62.2 and 2.63.1 through a manual adapter. It reproduces a known historical public-link revocation difference while preserving the owner's Download permission and the other user's work. This is neither a new vulnerability discovery nor a Duo repair of File Browser. A green historical-control job includes the old version's expected unsafe behavior; it does not certify that version as safe.
Challenges and evaluation
We did not demonstrate superior repair performance over strong ordinary Duo development. The original six-task, two-arm study stopped after six exposures when the Codex operator's usage limit interrupted observation; it had zero complete original task pairs. Six later sessions were prospectively documented as a separate exploratory continuation.
All ten assessable final artifacts across both arms passed a separately implemented 48-case evaluator, two supplied tests and twenty secondary cases each. One other final changed a protected test file; another missed the operator's observation deadline. Neither was quality-assessed or relabeled an incorrect repair. The tasks share a synthetic scaffold and the evaluator was written by the same project team, not an independent blinded benchmark. We make no repair-rate or speed advantage claim.
Earlier generated checks detected 8/10 known injected mechanisms versus ordinary regression's 10/10. Reusing the stronger observer later produced a post-hoc 10/10 tie on that disclosed set. We preserve the unfavorable result. Preparation time, reviewer effort and adoption value remain unmeasured.
What we learned
Authority timing is a policy choice, and physical effects need separate observation. Unverified execution must not become a green check merely because an outer command returned zero. Our contribution is the implemented policy-to-evidence-to-Duo workflow, combining established techniques rather than inventing a new authorization theory.
Coverage remains finite schedules, a cooperative worker and a registered sink. It does not establish atomic check-and-write behavior, every interleaving, unknown external effects, multi-worker correctness or hostile-process isolation. Hashes check observed consistency. Passing checks do not prove the entire application safe. The viewer displays saved evidence; changing a selector does not execute Duo or the application.
What's next
Evaluate setup and review costs with external users before claiming productivity gains, and add adapters only where the integration burden is justified. The demo video shows the earlier app-only repair; current source and CI also include the later reporting and File Browser controls described above.
Source and execution
The video combines recorded execution screens and labeled explanatory graphics with Kokoro synthetic narration; it is not a continuous live recording.
Built With
- gitlab
- junit
- python
Log in or sign up for Devpost to join the conversation.