maneuler / vaultWhat exists. What comes next.
Updated 2026-09-21. Every requested workstream is listed below. A proposal is not a shipped feature; a passing local check is not an independent audit. Native downloads keep their stated release behavior until rebuilt and tested.
How priorities are grouped
Planning groups assigned for this implementation: P0 security foundations (1–7), P1 product and adoption (8–29), P2 operational scale (30–38), P3 ecosystem/research (39–41). These are planning priorities, not delivered-release promises.
1. Audit preparation
Threat model, findings register, disclosure policy and repeatable web builds.
Next gate: Commission an independent review of a frozen source/build and publish remediation scope.
2. Responsible reporting
Standard security.txt and draft bounty scope use the confirmed current contact.
Next gate: Confirm a separate monitored inbox and owner-controlled PGP key before advertising them.
3. Memory and locking
Owned buffers, DOM clearing and 1/5/15-minute idle lock; iOS capture-cover source.
Next gate: Test rebuilt native apps on physical devices and measure remaining platform memory exposure.
4. Argon2id qualification
Local synthetic benchmark and published development-Mac measurements; 64 MiB/3 retained.
Next gate: Measure real 2 GB Android and old laptops before choosing any adaptive profile.
5. Signed release supply chain
Web build manifest, SBOM generator, checksums and pinned attestation workflow.
Next gate: Enroll/verify publisher identities and run protected release CI; sign and test each platform artifact.
6. Parser fuzzing and interoperability
29 mutation cases, terminal-block fix, external KeePassXC corpus and CI configuration.
Next gate: Run required checks in the owner repository and expand to continuous coverage-guided fuzzing.
7. Phishing-resistant autofill
Exact HTTPS-origin review, IDN ASCII warning and confirmation with a fresh tab check.
Next gate: Build and validate new extension packages in real Chrome/Firefox profiles before store submission.
8. Passkeys and credential providers
WebAuthn in a normal website requests a credential from an authenticator; it does not make that page a system-wide passkey provider. The current popup extension and Capacitor app have no credential-provider integration.
Next gate: M1: documented credential schema and external KDBX preservation vectors; no enrollment UI in production M2: Chromium/native provider proof with origin/RP binding, user verification, cancellation and negative tests M3: physical iOS/Android enrollment and authentication against independent relying parties; security review before rollout
Read the design proposal →9. Local TOTP authenticator
Entries currently contain password/card/note/page fields; there is no OTP parser, authenticator view or camera permission.
Next gate: M1: RFC known-answer vectors, strict URI/parser and protected KDBX round trips M2: entry editor, countdown, local import and native conditional clipboard clearing M3: physical mobile QR permission/denial tests; camera disabled outside scan view
Read the design proposal →10. Password policies and local health
The current generator offers a cryptographically random 24-character default, but no policy controls or health dashboard.
Next gate: M1: entropy/policy specification and deterministic RNG-edge/property tests M2: generator controls and documented site-policy presets with no external lookup M3: local health view that clears on lock and explains uncertainty
Read the design proposal →11. Opt-in breach checks
The website currently has connect-src none and no network client for vault data. An ordinary email breach lookup cannot be described as password-style k-anonymity.
Next gate: M1: network/privacy RFC and narrow endpoint/CSP design with independent review M2: mocked range protocol, zero-count padding, rate-limit and offline tests; manual opt-in UI M3: separately reviewed email monitoring service or omit it; publish metadata/retention terms before activation
Read the design proposal →12. Emergency access and recovery
The local-only app has no authenticated delivery service or trusted clock. A recipient who already has a decryptable key cannot be forced by client code to wait.
Next gate: M1: cryptographic protocol and abuse analysis for enrollment/revocation/clock rollback M2: isolated recipient grant prototype and owner notification/cancellation simulation M3: audited service, identity verification, recovery drill and opt-in policy before launch
Read the design proposal →13. Encrypted sharing with honest limits
Current exports share a complete encrypted file; no public sharing endpoint exists.
Next gate: M1: protocol and recipient-origin threat model plus schema/fuzz tests M2: local relay prototype, concurrent consumption and authenticated metadata tests M3: privacy/abuse review, operational expiry deletion, redacted logs and opt-in rollout
Read the design proposal →14. Native biometric unlock
OS-protected storage currently protects device pairing credentials, not the master passphrase. A UI biometric prompt alone is not cryptographic key protection.
Next gate: M1: per-platform key-wrapping contracts and threat model M2: macOS/iOS and Android secure-store prototypes with enrollment/lockout tests M3: Windows Hello implementation, physical-device validation and signed distribution
Read the design proposal →15. Encrypted file attachments
KDBX binaries are preserved on round trips but no attachment UI exists. The current full-buffer serializer and 8 MB file cap cannot stream arbitrary large attachments.
Next gate: M1: small-file quotas, metadata sanitization and KDBX binary round trips M2: download-only attachment UI plus corruption/quota/recovery tests M3: separate streaming-container RFC and audited implementation before raising limits
Read the design proposal →16. Desktop SSH agent
The Node CLI currently manages encrypted files; it does not expose an SSH agent socket or support SSH key entries.
Next gate: M1: protocol/library/license review and negative packet corpus M2: loopback/owner-only desktop signing prototype with OpenSSH client interoperability M3: policy UX, lock/revocation behavior, platform permissions and signed builds
Read the design proposal →17. Optional encrypted sync relay
Current Wi-Fi sync approves complete KDBX replacements. There are no accounts, billing, remote vault storage or cloud identity keys.
Next gate: M1: protocol, metadata/retention/cost review and local-only regression suite M2: isolated opaque-blob relay with device identity, revision compare-and-swap and rollback detection M3: independent audit, deletion/recovery drills, billing separation and explicit opt-in beta
Read the design proposal →18. Field-level conflict resolution
Sync currently compares entries but replaces a complete copy after review. There is no authenticated last-common-base history.
Next gate: M1: pure merge proposal model with property tests and encrypted-base lifecycle M2: conflict UI requiring explicit decisions and atomic encrypted commit/backup M3: native two-device race/disconnect/replay tests and KeePassXC round trips
Read the design proposal →19. Bring your own encrypted storage
The app currently exports encrypted files and has no provider OAuth or WebDAV/S3 adapter.
Next gate: M1: common ciphertext transport contract and local fake-provider tests M2: native WebDAV adapter with TLS, conditional-write and offline recovery tests M3: S3/Drive/Dropbox consent, token revocation and provider-review milestones
Read the design proposal →20. Ship iOS with a shared core and autofill
The existing Capacitor/Swift shell uses the shared JavaScript KDBX core and now compiles for the simulator. Apple enrollment/device signing and system autofill remain pending.
Next gate: M1: active Apple membership, bundle/entitlement review and signed physical-device build M2: system autofill, biometric/session and screen-capture tests on supported iOS versions M3: shared-core test-vector parity, migration backups and independent audit before switching the writer
Read the design proposal →21. Inline extension interactions
The extension currently uses activeTab and explicit click-to-fill. New review UX confirms the exact origin, but no content-script inline menu is installed.
Next gate: M1: permission/iframe/message threat model and hostile-page harness M2: accessible inline login/generator prototype with limited host grants M3: real Chrome/Firefox runtime tests, store policy review and passkey integration separately
Read the design proposal →22. Interactive demo and walkthrough
In-memory sample vault, real screenshots, captioned 30-second recording.
Next gate: Validate accessibility and isolation on additional supported browsers; no conversion metric is claimed.
23. Clear product positioning
Local-first, open-format, no-account headline and concrete sample action.
Next gate: Evaluate comprehension with consenting participants, not hidden analytics.
24. Honest comparison
Feature matrix names both current strengths and missing capabilities.
Next gate: Recheck primary product sources before every substantive update.
25. Trust and open format
KDBX portability explanation, signing boundaries, reproducibility evidence and status page.
Next gate: Publish an audit badge only after an actual independent audit and remediation sign-off.
26. Pricing
Free local mode; proposed Plus $2, Family $5, Teams $4/person monthly USD.
Next gate: Validate service cost and support capacity before enabling checkout or promising paid capabilities.
27. Docs, changelog and status
Getting started, supported imports, recovery, Wi-Fi troubleshooting and manual status.
Next gate: Add release-specific device screenshots and automated public availability checks.
28. Security education
Passphrases, breach response and cautious migration guidance.
Next gate: Review guidance against primary sources and add useful articles based on support needs.
29. Guided onboarding
Sample tour, setup instructions and printable recovery checklist; no telemetry.
Next gate: M1: local strength estimation with a reviewed zxcvbn dependency. M2: direct CSV parser and field mapping with hostile-file tests. M3: separate opt-in aggregate event design with no secret fields.
30. Organizations and shared vaults
No organization or shared-key service is active.
Next gate: M1: member/device key hierarchy and explicit admin recovery. M2: encrypted role-scoped sharing with rotation. M3: offboarding tests. Revocation protects future access; downloaded plaintext cannot be clawed back.
31. Compliance package
No SOC 2 certification, completed pen-test or legal compliance claim.
Next gate: M1: inventory data flows and processors. M2: owner/counsel-reviewed privacy, retention and DPA terms. M3: independent assessment and publish agreed summaries; SOC 2 Type II needs an evidence period and auditor.
32. Enterprise administration
No SSO/SAML, SCIM or remote admin panel exists.
Next gate: M1: identity and role threat model. M2: isolated SSO/SCIM provisioning, replay and deprovisioning tests. M3: redacted audit events and policy UX without exposing personal vault contents.
33. Developer secrets integrations
Current CLI manages local encrypted vault files. No hosted secrets API.
Next gate: M1: scoped capabilities and short-lived credentials. M2: owner-only local API with denial tests. M3: reviewed CI delivery with per-secret approval/rotation; never export whole vaults to build logs.
34. Coverage and end-to-end testing
Crypto/memory/interop/fuzz/lock/demo/browser tests added; no >90% claim.
Next gate: M1: collect real line/branch coverage. M2: test failure paths and merge properties once implemented. M3: raise a meaningful >90% gate on selected core/sync/merge modules and add real extension/golden checks.
35. Performance budgets
Empty-vault local benchmark only. The app does not support a tested 10,000-entry workflow.
Next gate: M1: physical-device unlock/memory baselines. M2: profile and virtualize large lists without breaking search/keyboard flows. M3: change size/entry limits only after tests and enforce stable CI regression budgets.
36. Release engineering
Versioned privacy page, hashes and web evidence. No signed auto-updater.
Next gate: M1: publisher signing/provenance and artifact identity. M2: signed version/channel metadata and anti-rollback protection. M3: staged opt-in beta, safe rollback procedure and tested policy diffs.
37. Crash diagnostics
No Sentry or crash-reporting SDK is present.
Next gate: M1: strict allowlisted event schema with no DOM/URL/breadcrumb/attachment collection. M2: opt-in local preview and one-tap disable. M3: seed-secret redaction tests and independently reviewed endpoint/retention policy.
38. Accessibility and localization
Keyboard/reduced-motion support and selected axe/mobile checks; no WCAG certification.
Next gate: M1: full WCAG 2.2 AA keyboard/screen-reader/zoom audit. M2: extract strings with ICU pluralization. M3: reviewed Spanish, Hindi, German, French and Portuguese translations and layout tests.
39. Public client source
Source archives exist; this workspace had no Git repository or remote. Review branches are isolated locally.
Next gate: M1: confirm repository and copyright/dependency ownership. M2: choose GPLv3-or-compatible licensing and contributor terms with owner review. M3: publish clean clients, required CI and contribution/security routes; no private keys in history.
40. Community integrations
No arbitrary-code plugin loader is shipped.
Next gate: M1: declarative theme/importer capability model. M2: isolated no-network sandbox with explicit permissions and size/time limits. M3: signed manifest/update review, revocation and hostile-plugin tests before opening an ecosystem.
41. Three-year cryptography research
No post-quantum security or DID interoperability claim. Existing KDBX format remains unchanged.
Next gate: 2026–27: inventory cryptographic dependencies and follow reviewed standards. 2027–28: compare hybrid/PQ prototypes, migration and recovery cost outside production. 2028–29: independent evaluation and opt-in pilots only if standards, interoperability and threat models justify them. DID remains a separate experiment.