Security and disclosure

Reporting

TODOthe security address — set LEGAL.contact.security in src/lib/site.ts

Also published at /.well-known/security.txt, per RFC 9116.

Send whatever you have. A rough description of the behaviour with the request that caused it is worth more than a formatted report, and you do not need to write an exploit to be taken seriously.

There is no bug bounty. No money, no swag, no points. Saying so on this page rather than in a reply three weeks later is the only fair way to handle it — you should know what you are and are not getting before you spend the evening. What is on offer is a fast, honest answer, credit in the release notes if you want it, and the fix shipping.

What to expect

Acknowledgement	Within 3 working days, from a person.
First assessment	Within 10 working days — whether we agree it is a vulnerability, and how severe.
Fix	Critical inside 7 days, high inside 30, everything else in a normal release.
Updates	At least every two weeks while it is open, without you having to chase.
Disclosure	Coordinated. Please give us 90 days, or until the fix ships if sooner.
Credit	Yours if you want it, in the release notes. Say so in your first message.

If we disagree that something is a vulnerability, you get the reasoning rather than silence. If we go quiet past those windows, you have not done anything wrong and you are free to disclose.

Safe harbour

Research done in good faith and within the rules below is authorised, and we will not pursue legal action or ask a provider to act against your account for it. If a third party comes after you for work that stayed inside these rules, say so and we will make our position clear to them.

The rules:

• Use your own licence, your own trial and your own machines.
• Do not access, modify or keep anybody else’s data. If you reach some by accident, stop, and tell us what you saw so we can measure the exposure.
• No denial of service, no load testing, no brute force against live endpoints. The rate limits are there — hitting a 429 is fine; trying to knock the server over is not, because the licence server going down stops other people’s software from opening.
• No social engineering of anyone, no phishing, no physical access attempts.
• Give us reasonable time before going public.

In scope

• The licence server API — validate, activate, deactivate, trial, checkout, portal, the Stripe webhook, and the admin endpoints.
• The Ed25519 entitlement signing and verification, and anything that produces a token the app will accept.
• This website, including the account area and its session handling.
• The Dispatch desktop application and its auto-update path.
• Anything that lets one customer see another customer’s key, address, machines or events.

Out of scope

Not because they do not matter, but because they are known, documented, or somebody else’s:

• Patching the licence check out of the installed app. Dispatch is JavaScript in an asar. Licensing says in public which fuses are set, which one is deliberately not, and that a determined person gets through anyway. That is a documented design limit, not a finding.
• Unsigned installers and the SmartScreen warning. Known, on the list, and stated on Download before anyone clicks.
• The read-only update token inside the build. Known and extractable. With the licence gate on, a leaked token gets someone installers they cannot run.
• Plugins not being sandboxed. Documented behaviour — the plugin host loads JavaScript from your own user-data folder with the app’s access. Report a way for a remote party to place a plugin there; that is a real finding.
• Vulnerabilities requiring an already-compromised machine or physical access.
• Missing security headers with no demonstrated impact, and reports produced by a scanner with nothing behind them.
• Anything in Stripe, Resend, Railway or GitHub — report those to them directly. Tell us too if it affects your data with us.

What is already true

Stated so you can start from the current position rather than rediscovering it:

• Entitlements are Ed25519-signed. The server signs and the app only verifies, so pointing an installed copy at another server by DNS, proxy or hosts file gets it tokens that fail verification. The API base is not a trusted value.
• The signing key exists only in the server’s environment and has never been in a repository.
• Admin endpoints require a bearer token, compared in constant time, at least 32 characters, and the server refuses to boot without one.
• Stripe webhooks are verified against the raw request bytes with a 5-minute timestamp tolerance, so a captured webhook cannot be replayed.
• Card data never reaches our servers. Checkout is hosted by Stripe.
• Every write endpoint is rate limited per address, and the database is reached over a private network with certificate verification on.

Encryption

TODOa PGP key for encrypted reports, if one is wanted — set LEGAL.contact.security in src/lib/site.ts

Until there is one, send the report in plain email. A vulnerability report that sat in a drafts folder because there was no key to encrypt it with is worse than one that arrived.