IRSB Security Audit Fixes, git-with-intent v0.6.0, and GitHub Profile Overhaul
Forty commits across five repos. The biggest day of January by commit count, and most of it was security work that made the IRSB protocol auditable.
IRSB Security Fixes (16 Commits)
Yesterday built the audit scaffold. Today started closing the findings.
HIGH Severity Fixes
SEC-001: Reentrancy in bounty settlement. The settleBounty function transferred tokens before updating the bounty status. Classic reentrancy vector — a malicious resolver contract could re-enter settleBounty during the token transfer callback and claim the bounty twice.
The fix applies checks-effects-interactions: update the bounty status to RESOLVED before calling transfer. Added a reentrancy guard modifier as defense-in-depth. The modifier uses OpenZeppelin’s ReentrancyGuard rather than a hand-rolled version.
SEC-002: Unchecked ERC-20 return values. The settlement function called token.transfer(resolver, amount) without checking the return value. Some ERC-20 tokens (notably USDT) return false on failure instead of reverting. The bounty would be marked as settled but the resolver would receive nothing.
The fix uses OpenZeppelin’s SafeERC20 library, which wraps transfer calls and reverts on false returns. Every token interaction in the codebase got updated, not just the settlement function.
SEC-003: Missing access control on deactivate. The deactivateOperator function had no onlyOwner or role check. Anyone could deactivate any operator. The fix adds a role check: only the operator themselves or an address with the ADMIN_ROLE can deactivate.
SEC-005: Frontrunning on bounty claims. When a solver submitted a claim, the transaction sat in the mempool where a frontrunner could see the solution and submit their own claim with higher gas. The fix implements a commit-reveal scheme: solvers first commit a hash of their solution, wait one block, then reveal. The commit locks the solver’s address to the bounty, so a frontrunner copying the revealed solution gets rejected.
Invariant Tests
Each security fix got a corresponding invariant test. These aren’t unit tests that check a specific input/output pair — they’re property-based tests that assert invariants hold across random inputs.
- Reentrancy invariant: “After
settleBounty, the bounty balance is zero and exactly one transfer event was emitted.” Foundry’s invariant testing framework generates hundreds of random call sequences trying to violate this. - Transfer invariant: “Every token transfer in the protocol either succeeds and updates balances correctly, or reverts entirely.”
- Access control invariant: “No function with a role modifier succeeds when called by an address without that role.”
Slither CI Gates
Slither static analysis is now a required CI check. The configuration is tuned to the codebase — detectors for reentrancy, unchecked-transfer, and unprotected-upgrade are set to error. Informational findings (variable naming, gas optimization suggestions) are set to warning.
The CI job runs Slither in a Docker container with a pinned version (0.10.0) so results are reproducible across environments. The job fails on any HIGH or CRITICAL finding. MEDIUM findings are logged but don’t block merge.
Regression Tests
Beyond the invariant tests, each SEC fix got a specific regression test that reproduces the original vulnerability. SEC-001’s regression test deploys a malicious resolver contract that attempts reentrancy and asserts the attack reverts. SEC-005’s test submits two claims for the same bounty and asserts only the committed solver’s claim succeeds.
These tests serve a documentation purpose: a future developer reading test/security/SEC-001-reentrancy.t.sol understands exactly what the vulnerability was and how it’s prevented.
Governance Suite
The monorepo got the full governance treatment: CONTRIBUTING.md (coding standards, PR process, commit conventions), SECURITY.md (responsible disclosure, PGP key, bounty program details), GOVERNANCE.md (decision-making process, role definitions), and CODE_OF_CONDUCT.md.
These aren’t checkbox compliance files. The CONTRIBUTING guide describes the actual PR review process — two approvals required, one must be from a contract-aware reviewer for any Solidity changes. SECURITY.md lists a PGP key and an email for responsible disclosure. GOVERNANCE.md documents the three-tier decision model: routine changes (single maintainer), architectural changes (two maintainers), and protocol changes (all maintainers plus a governance vote).
Operator-Grade Appaudit
Ran the full appaudit against the monorepo. The audit covers code organization, test coverage, CI/CD maturity, documentation completeness, and dependency hygiene. The results feed into the v1.0.0 readiness assessment.
git-with-intent v0.5.1 and v0.6.0 (10 Commits)
Two releases in one day. v0.5.1 was a bugfix release. v0.6.0 was a feature release.
v0.5.1: Health Checks
The gwi health command checks the local installation: is the Git hooks directory configured, is the ReviewerAgent reachable, are the required configuration files present, and is the version compatible with the team’s minimum version constraint.
This command exists because support requests were 80% “it’s not working” where the answer was “your hooks aren’t installed.” Now the first troubleshooting step is gwi health and the output tells you exactly what’s wrong.
v0.6.0: Run Lifecycle Specification
The run lifecycle defines the state machine for agent execution: PENDING, RUNNING, PAUSED, COMPLETED, FAILED, CANCELLED. Each transition has preconditions and side effects documented in a formal specification.
The specification matters because git-with-intent supports long-running agents (code reviewers that watch for new PRs, continuous integration agents that run on every push). These agents need to be paused, resumed, and cancelled gracefully. Without a formal lifecycle, every agent implemented its own state management.
The implementation adds lifecycle hooks: onStart, onPause, onResume, onComplete, onFail, onCancel. Agents implement the hooks they care about and the runtime manages the state transitions.
Bounties Phase 2 Intelligence (7 Commits)
Phase 2 adds the intelligence layer on top of the basic bounty CRUD from Phase 1.
Maintainer profiles now track response time, approval rate, and average bounty size. This data helps bounty hunters prioritize — a maintainer who reviews within 24 hours and has a 70% approval rate is a better bet than one who takes two weeks and approves 20%.
The intelligence layer also adds trend detection: if a repository’s bounty volume is increasing, it surfaces in the “trending” feed. If a maintainer’s response time is degrading, it shows a warning.
GitHub Profile Overhaul (6 Commits)
Inspired by steipete’s GitHub profile — the one that reads like a portfolio rather than a default README with contribution stats.
The new profile leads with a one-sentence bio, lists the three flagship projects (IRSB, git-with-intent, claude-code-plugins) with one-line descriptions, and links to the portfolio site. No contribution graphs, no trophy widgets, no “I’m currently learning” sections.
The implementation uses GitHub’s profile README feature with clean Markdown. No badges except build status on the flagship repos. The design principle: if someone lands on my GitHub profile, they should understand what I build in 5 seconds.
Forty commits. IRSB’s security posture went from “we know the problems” to “we’ve fixed the critical ones and can prove it.” git-with-intent has a real lifecycle model. The GitHub profile looks like it belongs to someone who ships.