2 Commits

Include renames

Author	SHA1	Message	Date
Ayobami Adegoke	e16afac7b9	ci: add supply-chain guards — permission allowlist, gitignore rules, manifest checks, pinned actions (#84) ... * ci: add supply-chain guards - permission allowlist, gitignore rules, manifest checks, pinned actions This template's threat model is unusual: it ships pre-approved Claude Code permissions (.claude/settings.json) and CLI code that every fork user executes via those permissions. A plausible-looking PR could therefore ship risk to every forker: widen a permission to Bash(*), weaken the personal-data gitignore rules, or smuggle code execution into bun install via a lifecycle script. Nothing checked for these mechanically. New job security-guards runs tools/security_guards.py (stdlib only): - settings.json: every permissions.allow entry must be in an exact, in-repo allowlist. The guard makes permission changes loud, not impossible - a PR that intentionally widens permissions must update the allowlist in the same diff, so the widening is explicit and reviewable - .gitignore: the personal-data rules (tracker, documents/**, cv/main_*, salary data, seen_jobs) must all still be present - the mirror image of the placeholder-integrity job - .agents/**/package.json: no lifecycle scripts (preinstall/install/ postinstall/prepare/prepack) and no trustedDependencies, which would execute arbitrary code during bun install on users' machines New job dependency-review (PRs only): actions/dependency-review-action flags newly introduced vulnerable or malicious dependencies, fail-on-severity high. Workflow hardening: explicit top-level permissions: contents: read (least-privilege token), and all actions pinned to commit SHAs resolved from the same major tags already in use (checkout v4, setup-python v5, setup-bun v2), with the tag recorded in a comment. Honest limit, recorded in the workflow header: a PR can edit this workflow itself, so these guards catch accidents and casual attempts, not a determined author. Branch protection with required checks and human review of workflow/settings diffs remain the real backstop. Verified locally: positive run passes; injecting Bash(*) into settings.json, deleting the tracker gitignore rule, and adding a postinstall script each fail the guard with the intended message, and reverting restores a clean pass. * ci: scope dependency-review to upstream PRs - forks lack Dependency graph by default Verified on a fork: the action fails with 'Dependency review is not supported on this repository' until Dependency graph is manually enabled, and forks don't inherit it. Guarded with the same github.repository == upstream condition the other upstream-only jobs use. With the graph enabled the action passes, so the config itself is sound. * ci: probe Dependency graph before dependency-review - warn and pass when unavailable The upstream PR run showed Dependency graph is disabled on the upstream repo too (the action hard-fails: 'Dependency review is not supported on this repository'), not just on forks. Only the repo owner can enable it, so a hard red X here is friction, not signal. The job now probes the dependency-graph SBOM endpoint with the workflow token first: HTTP 200 runs the real review; anything else emits a ::warning:: naming the setting to flip (Settings -> Advanced Security -> Dependency graph) and passes. Same graceful-skip pattern the workflow uses for optional tools - the check self-activates the moment the graph is enabled, no workflow change needed.	2026-07-09 06:03:01 +02:00
Ayobami Adegoke	6477987608	ci: add GitHub Actions workflow - LaTeX smoke compiles, skill lint, CLI typechecks, placeholder integrity (#59) ... Every PR to this repo is currently verified by hand. This adds the checks a machine can do: - latex-smoke: compiles cv/main_example.tex (lualatex) and the new cover_letters/cover_example.tex (xelatex) in the texlive/texlive container, failing on any LaTeX error. Exact page-count assertions (CV=2, cover letter=1) run on the upstream repo only - lint (tools/lint_skills.py, also runnable locally): every SKILL.md has parseable YAML frontmatter with name+description (frontmatter breakage happened before - 37a0eed), allowed-tools 'bun run <path>' targets exist, command files start with a '# /<name>' title, settings.json is valid JSON with a permissions.allow list - cli-typecheck: bun install + tsc --noEmit for all five portal CLIs (matrix, fail-fast off) - placeholder-integrity (upstream only): tracked template files still carry their placeholder tokens, catching accidental personal-data commits before they land Fork-friendly by design: /setup personalizes CLAUDE.md, the skill files, and main_example.tex in forks, so placeholder checks and exact page counts are guarded with github.repository == upstream; compile success and lint run everywhere. Live CLI smoke tests are deliberately excluded: network-flaky, and linkedin-search is personal-use-only per its own ToS warning - CI-automated requests would violate it. CLIs are typechecked instead. The cover letter previously had no tracked example (cover_*.tex is gitignored), so cover_example.tex is new: a placeholder letter following the documented 06 structure, demonstrating the correct itemize-outside- lettercontent pattern. It doubles as the structural reference /apply Step 2 looks for on fresh clones, which until now matched nothing. The gitignore exception is ordered after Cover_*.tex because case-insensitive filesystems match that pattern against cover_example.tex too. Writing it surfaced a latent bug in the documented template itself: 06-cover-letter-templates.md's structure ends with \closing{Kind regards,\} - but cover.cls appends its own \, and the doubled break produces '! LaTeX Error: There's no line here to end.' on every compile (nonstopmode swallows it, so it went unnoticed). Fixed in 06 and noted in the example.	2026-07-08 17:09:33 +02:00