WhyQR seeks Rust code review for auditable password manager core

WhyQR was not asking for a quick thumbs-up. It asked Rust developers to inspect the part that matters most in a password manager: the security core, the boundaries around it, and whether the design stays auditable when secrets are on the line.

The request landed on June 2 in The Rust Programming Language Forum’s code-review category, where the user Davros described WhyQR as having an open-source Rust security core while other components remained source-available for auditing. That split mattered. Rather than presenting the whole product as fully open, the post drew a bright line around the code handling the most sensitive work and invited scrutiny where trust is hardest to earn.

Davros asked for feedback on secret handling, module boundaries, error handling, dependency risk, testing strategy, and long-term auditability. That is less a product demo than an architecture review under security constraints. The shape of the request suggests the core is meant to be read, reasoned about, and challenged, not merely downloaded.

WhyQR’s own site frames the product as a local-vault password manager with a server-gated unlock. The vault stays on the device, plaintext never leaves the device, and unlocking requires an internet connection, which means copied vault files cannot be brute-forced offline at scale. The tradeoff is explicit: if the servers are down, unlocking is temporarily unavailable. WhyQR also says independent validation is planned, a detail that reinforces the central question in the forum thread: can the design be trusted because it is open to review, or because it has been proven under review?

The GitHub repository description for WQR_Rust_core helps explain why the forum focus stayed on the core itself. The Rust code is described as handling client-side crypto, codecs, passkey helpers, and C ABI bindings, which puts the security boundary right where Rust developers would want it: in a small, inspectable layer with well-defined responsibilities. That is exactly where clean module structure and narrow dependencies can turn a security claim into something maintainable.

The broader lesson reaches beyond WhyQR. OWASP says passwords should never be stored in plain text, and its cryptographic storage guidance warns against reversible encryption for passwords at rest. Rust tools such as the secrecy crate push in the same direction by making secret access explicit, reducing accidental leakage in debug output, and wiping secrets from memory on drop. That is the standard the WhyQR thread implicitly set for itself.

In the end, the post was not really about a password manager at all. It was about whether an open Rust core, drawn tightly enough around secrets, can earn trust by being easy to audit before anyone is asked to rely on it.