Proof of Code

This repo has two parts:

• proof-of-code/: a VS Code extension that records file snapshots and edits, then uploads them to the local server.
• proof-of-code-server/: an Axum server that verifies signed student identities, stores replay logs, serves the replay UI, and can provision student starter repos.

config.toml

The server now requires a local config.toml file in proof-of-code-server/. A sanitized example is included at proof-of-code-server/config.example.toml. Copy it to config.toml and fill in your real secrets locally. This fully replaces the previous .env and environment-variable startup path.

It defines:

• server settings such as bind address, log directory, repo root, default template, and signing secret
• Google OAuth credentials and redirect URL
• GitHub organization provisioning settings and GitHub OAuth credentials
• replay reviewer allowlist
• ingest timestamp thresholds
• suspicious-event thresholds
• the allowed project registry

Each configured project has:

• name: canonical slug used in session IDs and repo paths
• label: display name shown in provisioning and replay
• repo_template: optional per-project template override

.submit file

The extension reads credentials from a .submit file at the workspace root:

[user]
directory_id = "ashtree@systems"
project_name = "systems"
signature = "hex-hmac-signature"

directory_id becomes the upload session_id, project_name is used for local validation/UI, and signature is sent with every upload. The Rust server verifies the signature against the full canonical username@project_name ID using server.signing_secret from your local config.toml.

Running the server

Start the Rust server from proof-of-code-server:

cd proof-of-code-server
cargo run

Startup now fails if config.toml is missing, malformed, or missing required fields.

HTTPS / Let's Encrypt

For proof-of-code.ash.computer, the recommended production setup is:

• keep the Axum server bound to 127.0.0.1:3000
• run Caddy on ports 80 and 443
• let Caddy obtain and renew Let's Encrypt certificates automatically

A starter Caddy config is included at proof-of-code-server/Caddyfile:

proof-of-code.ash.computer {
	reverse_proxy 127.0.0.1:3000
}

This means the Rust server should not bind directly to 0.0.0.0:443. The public HTTPS endpoint lives in Caddy, while the app stays on localhost behind the reverse proxy.

Generating a student repo

You can generate a signed starter repo directly from the Rust server binary:

cd proof-of-code-server
cargo run -- generate-student-repo --session-id ashtree@systems --output ./generated-student-repos/systems/ashtree

If server.repo_template is configured, or the selected project has its own repo_template, that template is copied first and then a .submit file is written into the new repo.

Google-based provisioning

When Google and GitHub OAuth are configured, the server exposes:

• GET /auth/google/start
• GET /auth/google/callback
• GET /auth/github/start
• GET /auth/github/callback
• GET /replay
• GET /api/replay/sessions
• GET /api/replay/sessions/:id
• GET /api/replay/sessions/:id/events
• GET /api/replay/sessions/:id/raw

Provisioning is now a 2-step flow:

1. a verified Google user signs in
2. the server renders a project picker sourced from config.toml
3. the student links their GitHub account
4. the server creates a GitHub repository in the configured organization and a local starter repo

The resulting canonical session ID is always username@project_name, and repos are created at:

<repo_root>/<project_name>/<username>

For demo purposes, replay access currently accepts any signed-in Google account.

GitHub provisioning requirements

GitHub provisioning uses the gh CLI from the server host. The machine running proof-of-code-server must have:

• gh installed
• gh auth status already authenticated with enough permission to create repos in the configured organization
• a valid GitHub OAuth app configured in config.toml

GitHub repos are created with the name format project-username, such as web-wzhang99.