jcoffey-dev
9c44a28197
It had none: no security policy, no contributing guide, no code of conduct, no sponsor link, and no CI. A public repository with an administrative interface in it should at least say where to send a vulnerability, so that part names what is worth reporting here specifically -- a session acting beyond its permissions, one tenant's data reaching another, a token landing somewhere that outlives the session -- and where a report goes if it turns out to belong to the server or to upstream. CI is what a contributor can run: typecheck, lint, test, build. Nothing in it needs a live server, so a red run means the code, not the runner.
1.4 KiB
Security policy
Supported versions
INBUXA Admin is developed on main, and security fixes are applied there and
in the latest release. Older tags are not backported.
| Version | Supported |
|---|---|
main and the latest release |
✅ |
| Older releases | ❌ |
Reporting a vulnerability
Please don't open a public issue for a security problem. An issue is visible to everyone, including whoever would use it, before there is a fix.
Report it privately by email to:
johnellisATlinuxDOTcom
Include as much as you can of: what it lets someone do, how to reproduce it, the version or commit affected, and whether it needs an authenticated session or a particular role.
This is an administrative interface, so a few things are worth calling out as in scope even though they are not bugs in the usual sense: anything that lets a session act beyond the permissions its account holds, anything that leaks another tenant's data, and anything that exposes a token or a secret to a place it should not reach — the URL, the page, or storage that outlives the session.
You'll get an acknowledgement within a few days. A report that turns out to affect the mail server rather than this interface will be moved to inbuxa-server, and one that affects upstream Stalwart's web interface will be passed to Stalwart Labs with credit to you.