Security
How to tell us about a vulnerability, what happens next, and an honest account of where the weak points are.
Reporting something
security@eeg.studio, or open a private advisory on the
releases repository.
Machine-readable contact at
/.well-known/security.txt.
Please include what you did, what happened, and what you expected. A proof of concept helps enormously. If you need an account or test data to demonstrate it, ask and we will set one up.
Please do not run automated scanners against the production site. It is one small project on shared infrastructure, and a scan is indistinguishable from an attack. Ask first and we will give you what you need.
What we commit to
| We will | Within |
|---|---|
| Acknowledge your report | 3 working days |
| Tell you whether we accept it, with reasoning | 10 working days |
| Fix a critical issue, or tell you why we cannot | 30 days |
| Credit you publicly, unless you prefer otherwise | On release |
This is a one-person project. If a deadline slips you will hear why rather than hearing nothing. We will not threaten anyone who reports something in good faith, and we will not ask you to sign anything before we look at it.
Scope
In scope, most wanted first
- Anything letting one account act as another, or read another's data.
- Anything letting a published extension escape its stated behaviour, or letting a package bypass review.
- Anything exposing an email address or account identifier.
- Anything letting an unapproved marketplace entry become publicly visible.
- Injection, in the site or in the desktop application.
Out of scope
- Missing security headers with no demonstrated impact.
- Rate limits on read-only endpoints.
- Reports produced entirely by a scanner, with no analysis.
- Social engineering of us or of our users.
- That extensions execute code with the user's permissions. That is the documented design, stated on every extension page and confirmed at installation. An escape from that model is in scope; the model itself is not.
How the system is built
| Area | What is in place |
|---|---|
| Authentication | Clerk sessions, verified server-side against its JWKS. The author of anything is taken from the verified token, never from the request body. |
| API tokens | Only a SHA-256 is stored. Reading the database yields nothing usable. |
| File uploads | Keys are namespaced per user; the server refuses any other prefix, so one author cannot overwrite another's file. |
| Uploaded packages | Static analysis over the Python AST before review, flagging shell execution, dynamic imports, shipped binaries and archive path traversal. |
| Installers | SHA-256 published, and Ed25519 signatures verified before an update is executed. The signing key exists only as a CI secret. |
| Differential updates | Both ends hashed. A patch applied to the wrong source produces a corrupt binary silently, so every assumption is checked before anything runs. |
| Write endpoints | Turnstile plus per-account rate limits. |
| Transport | HTTPS only, HSTS, on Cloudflare. |
Where the weak points are
Stating these is more useful than claiming there are none.
- Extensions are not sandboxed. An installed extension runs Python with your permissions. Review and the static analysis reduce the risk; they do not remove it. Sandboxing is R-005.
- Installers are not yet code-signed. Windows shows a warning on first launch, and a user cannot currently distinguish our installer from a substituted one by signature alone. They can by checksum. This is R-003.
- Review is done by one person. Every marketplace submission is read by hand. That scales badly, and it is the honest limit of the current model.
Acknowledgements
Nobody yet. Reporters who ask to be named will be listed here with the issue they found.