Key takeaways
- The web panel cannot run commands: a separate root agent accepts only typed, allow listed operations.
- High risk actions need a fresh passkey or code, and every change is written to a hash chained audit log.
- Releases and add-ons are signed, older releases are refused, and a release that does not start is rolled back.
- Known gaps are published: a signed manifest without an expiry, unpinned repository keys and no external pentest yet.
Security claims are cheap, so this post sticks to what you can check. It summarises the security page and the security model, which hold the detail.
Least power for the part facing the internet
The web panel runs as an unprivileged user. It cannot run commands. Anything that needs root goes to a separate agent that accepts typed, allow listed operations, validates their parameters and runs programs as argument lists. There is no shell string to escape from, and an operation the agent does not know is refused.
Sessions and approvals
Sign in with passkeys, a password with a second factor or both. Actions with high or critical risk need a fresh passkey or code at the moment you run them, so a stolen session alone cannot do the damage. A browser kept signed in with a PIN is proven by a key that cannot leave it, together with a cookie that changes at every visit, so a stolen cookie gets nothing. You can end any signed in device from your Security page.
Every firewall change arms a rollback timer. If you do not confirm it, the previous rules come back, so a bad rule cannot lock you out.
A log that shows tampering
Changes are written to an audit log in which each entry includes a hash of the one before. Signed checkpoints can be copied off the server. Verifying the chain is an action of its own, and a break is reported as an incident.
Updates you can trust
Releases and Store add-ons are signed. The key is built into the program, and the root agent checks a release again before it runs. An older release is not accepted as an update. A release that does not start is replaced by the previous one together with a copy of the database. The installer verifies the release manifest's signature, size and checksum before it installs anything.
What was audited
Four white box reviews on 10 and 11 October produced 15 findings. A security and code audit on 19 October found 15 more, three of them high. A second audit on 20 October, of everything built after the first, found 13, three of them high. None was critical. All are fixed, and the testing post has the counts by severity.
What is still open
- The signed release manifest has no expiry date yet, so someone who can block updates could keep an installation on an older release unnoticed.
- Package repository keys that the installer adds are not yet pinned by fingerprint.
- An independent external penetration test has not started.
We would rather you read this list here than learn it later. To tell us about a problem, email info@respiresoft.com with the subject RespireCloud security report.
Your data stays yours
RespireCloud is software you install. This website sets no cookies of its own besides an optional partner code, and runs no analytics. Backups are standard restic repositories that go where you choose, and a lab run rebuilt a whole server on a blank node in 312 seconds from backup, with a list of what does not come back.
Questions
How do I report a vulnerability?
Email info@respiresoft.com with the subject RespireCloud security report. The contact and policy are also in security.txt on this site.
Is customer data sent to RespireCloud?
No. RespireCloud runs on servers you control, and your customers' sites, mail, databases and files stay there. Backups go to storage that you pick.