Verify

Proving you own the repo

Before we run a full check, you commit one small file to the repo. It stops anyone from checking an app they don’t control, and it takes about thirty seconds.

Why we ask

A report shows exactly which tables a stranger can read and how. That is useful to the app’s owner and useful to an attacker, so we only run the full check for someone who can change the repo. Committing a file is a simple test of that.

It also means we need no GitHub permissions at all. You don’t install anything, sign in with GitHub or hand over a token. We read the public repo like any visitor would.

How it works

1. You submit your repo and email. Your check page shows a file name, patchlabs-verify.txt, and a one-time code that looks like patchlabs-3f9a1c0b7d2e4a65. We email you the same details.
2. Press Add the file on GitHub. It opens GitHub’s new-file page on your default branch with the name and code already filled in. Press Commit changes.
3. Back on the check page, press I’ve added it. We look for the file, and if the code is there your check joins the queue.

https://github.com/OWNER/REPO/new/BRANCH?filename=patchlabs-verify.txt&value=patchlabs-3f9a1c0b7d2e4a65

From the command line instead

echo "patchlabs-3f9a1c0b7d2e4a65" > patchlabs-verify.txt
git add patchlabs-verify.txt
git commit -m "Verify repo for PatchLabs"
git push origin HEAD:main   # use your default branch name

With the API

For a free check, POST /checks returns the check ID, and GET /checks/{id} returns verify: {file, code, add_url} while it waits. After committing, call verify:

curl -s -X POST https://api.patchlabs.dev/checks/$CHECK_ID/verify
# {"status": "queued"}

What we check, exactly

Where

A file called patchlabs-verify.txt at the root of the repo, on the default branch (usually main). Not in a subfolder, not on another branch.

What

The file must contain your code. Extra whitespace or a trailing newline is fine.

How

We read it through GitHub’s contents API, which is always up to date. If GitHub’s limit for anonymous requests has been reached, we fall back to raw.githubusercontent.com, which can lag a few minutes behind a new commit.

How often

Only when you press “I’ve added it” (or call the verify endpoint). Press it again after a minute if it doesn’t find the file the first time.

Verifying a monitored app

When you add an app to a workspace, it gets its own code and the same file check. The difference is that an app is verified for good: once the file is found, the first check is queued automatically, and every later check (scheduled, run-now or from CI) skips verification.

curl -s -X POST https://api.patchlabs.dev/apps/$APP_ID/verify \
  -H "Authorization: Bearer $PL_SESSION"
# {"verified": true, "check_id": "…"}

After verification

• You can delete patchlabs-verify.txt once the check has started. Nothing else depends on it.
• The code proves one thing for one check (or one app). It grants no access to anything and is useless to anyone else.
• Keep your check page’s address. It is how you get back to the report, and it is in the email we sent.

Troubleshooting

Private repos

Not yet. Checking private repos needs a GitHub App with read access, which is coming. Until then the full check works on public repos only. If you need a private repo checked now, email the founder.