Reporting a security vulnerability

Do not report security vulnerabilities here. This board is public and operated by a third-party vendor. Read https://tovio.dev/security and use the private channel it names. Never paste repository contents, file paths, diffs, tokens, keys, or other people's data — describe the behaviour instead.

Where to send it

Email security@tovio.dev. The same address is published at https://tovio.dev/.well-known/security.txt, and the full policy — scope, severity, and the coordinated-disclosure process — is in the project's SECURITY.md.

An honest statement of what that channel is

Reports currently travel over ordinary email. There is no published PGP key, and the repository's private vulnerability reporting is not published either. Until one of those exists the intake is a mailbox, and we would rather say so than let you assume an encrypted or verified channel:

• Keep proof-of-concept material minimal.
• Never include live secrets, production credentials, real keys, or another party's data.
• A description of the flaw and the property it breaks is worth more to us than a working exploit against real data.

What a good report contains

• What the issue is and which guarantee it breaks — cite a threat-model property or a requirement identifier if you can.
• The affected component, the version or commit, and the platform.
• Steps to reproduce, a minimal synthesised proof of concept, or a failing test, built from data you own.
• The impact as you see it, and any remediation you would suggest.

Why it matters more here than elsewhere

TOVIO's whole reason for existing is enforcing access cryptographically. A bug in the crypto or permission layer does not produce a cosmetic defect — it can expose protected file content, leak key material, make a forged signature verify, let an audit entry be altered without detection, or let an agent read outside its token's scope. Those reports are treated as the highest-priority work in the project.

What happens next

The project follows coordinated disclosure: reproduce it, write a regression test that fails without the fix, fix it in private, agree a disclosure date with you, release, publish an advisory, and credit you unless you would rather stay anonymous. Every critical vulnerability also gets a public technical post-mortem once users have had a window to upgrade.

The response commitments written into SECURITY.md attach to a verified private intake channel, and that channel is not published yet. Today's intake is the mailbox above, and the honest position is that those commitments begin when the channel they were written for does.

Check the known limitations first

Some things a reader might expect from "cryptographically enforced permissions" are deliberate, documented limits of the profile that is actually implemented rather than bugs — revocation not un-decrypting content someone already holds, write control being enforced by the relay and therefore detectable rather than mathematically impossible, policy manifests being readable by design. They are listed in the project's threat model, and reading it first can save you the effort of reporting something already acknowledged in writing. A report that one of those can be bypassed, rather than that it works as documented, is exactly what we want.

If you already posted it publicly

Tell us at the address above. The post is taken down without a public reply, you are contacted privately with the disclosure route, and the content is not re-posted anywhere — including the project's internal board. That is the documented procedure, not an improvisation.

What is not a security report

A code-of-conduct concern goes to conduct@tovio.dev, and a privacy or data request to privacy@tovio.dev. Neither belongs in the security mailbox, and neither belongs on a public board.