SafeLibs

 ▐▛███▜▌   Claude Code
▝▜█████▛▘  Optimus 9000.1 · Claude ALL_YOUR_MONEY_PLAN
  ▘▘ ▝▝    /home/YOU
                                                                                
────────────────────────────────────────────────────────────────────────────────
❯ Change this repository from Rust to YOUR_LANGUAGE_HERE
────────────────────────────────────────────────────────────────────────────────

Any answer to this question will be meaningless, because it will be obsolete in a few weeks and I don't want to update this README that often.

rofl

In all seriousness, no one but the AI has ever looked at this code, and that goes for both the actual library reimplementations and the pipeline itself. Even if the libraries are perfect (and I'm sure they're not!), the best they'll do is protect against some memory safety issues in the original library. The actual programs using these libraries can still be vulnerable, or other libraries can be vulnerable, or the unsafe parts of these libraries can still be vulnerable, or there could be new and exotic non-memory errors in these libraries, or these libraries might set your computer on fire and turn your AI agent against you. I don't use these things, and you'd be crazy to, but they're there if you want to try them out!

These libraries pass adapted test cases from the original projects, and work in a drop-in manner with at least one client application. Beyond that, who knows!

If you still have a sandbox on in your AI agent, you should probably not use these libraries. If your agent's sandbox is off, you have already made the leap!

Unfortunately, despite Claude's dominance, Codex gives FAR more tokens in their top plan, so that's what we're using here. If you harness it brutally enough, like it's harnessed here, it sometimes works!

This repo uses a four-stage pipeline driven by Juvenal (https://github.com/zardus/juvenal), a workflow manager named after the Roman poet — riffing on "who watches the watchmen?" Each stage uses one or more Juvenal workflows to achieve and verify its goals despite agentic laziness, and each successful stage produces a git tag in the respective repo.

Juvenal leans on a behavioral quirk of coding agents: they will happily cut corners on their own work, but have no incentive to cover for another agent's shortcuts. After every implementation step, several fresh-context validation agents check the result against different criteria; anything missing bounces back to the implementer, dozens of times if necessary. The Port stage in particular doesn't share a workflow across libraries — a planning agent drafts and iteratively refines a library-specific workflow before any porting starts, because no single template fits every C library.

1. Recon - pull the original source (via Ubuntu's source packages) and existing CVEs, so the port has historical context for known non-memory issues.
2. Setup - prepare the source for porting, rewriting tests to use public library APIs (so they survive a clean reimplementation) and adding new ones, both directly against the library and through dependent applications.
3. Port - do the rust port. A planning agent first builds a library-specific workflow, then implementation and validation agents execute and check it step by step.
4. Test - exercise the port against additional client applications and the validator suite.

The full pipeline definitions live in the pipeline repo.

Each port is a regenerable artifact — the workflow can be rerun from scratch against a new upstream release. There's also a dedicated upgrade stage in the pipeline that's intended to be cheaper than full retranslation, though it hasn't been battle-tested yet.

The current focus is Ubuntu drop-in replacements via apt, which forces strict ABI compatibility and shapes a sizable chunk of the unsafe-block count. Distributions with stricter, content-addressed semantics (like Nix) would be a better fit for agent-generated replacements; if you're interested in extending coverage there, get in touch.

We can't accept code patches against the ported libraries — we don't audit the generated Rust closely enough to reason about adversarial PRs. We do accept reproducer testcases against the validator repo — the Test stage picks those up and re-runs the affected port until it passes.