Security Policy

How to report a security problem in the Open Aquarium Project’s specifications, firmware, or tools, and what happens after you do.

What This Covers

• The reference firmware for the controller and modules, in hardware/.
• The tools and software libraries, in tools/ and software/.
• The website, and the workflows that build and publish the project’s files.
• The specifications: a flaw in a specification that makes equipment following it insecure, such as a weakness in the Device Protocol or in Security and Access.
• The project’s accounts and signing keys, listed in docs/project-assets.md.

A problem in a maker’s product goes to that maker, under its own vulnerability disclosure policy. If the cause is in a specification, report it here as well.

How to Report

Report security problems privately, never in a public issue.

• GitHub: use private vulnerability reporting, at https://github.com/openaquariumproject/openaquariumproject/security/advisories/new.
• Email: address to be added.

Include, if you can:

• what is affected: the specification and section, or the file and commit;
• how to reproduce the problem;
• what an attacker could do, especially to equipment that heats, pumps, doses, or switches power; and
• whether anyone else knows about it.

A safety problem that nobody could exploit, such as a fail-safe default that could harm livestock, can go in a public issue, so that everyone sees it. If you are not sure which it is, report it privately.

What Happens Next

1. The project acknowledges your report within 7 days.
2. It tells you whether it accepts the problem, and then reports progress at least every 30 days until it is fixed.
3. It fixes the problem, and publishes a GitHub security advisory that says what was affected and what fixed it. A flaw in a specification is fixed by a new revision, and the advisory names the revisions affected.
4. The advisory is published when the fix is ready, and no later than 90 days after your report, unless you and the project agree on more time. It names you only if you ask.

When a problem affects a specification, the project tells every maker known to implement it, at the same time and before the advisory is published, so that they can prepare their own fixes. Known implementers are the Licensees listed in Notices, and any other maker who asks the Maintainer to be told. No maker, including a company related to a Participant, is told earlier or more than the others.

If a key that signs the project’s releases, or an account that publishes them, is compromised, the project says so publicly as soon as it knows, in an advisory and in an announcement.

Supported Versions

The project has no releases of its firmware or software yet. Until it does, fixes go into main, and only the latest code there is supported.

Research in Good Faith

Research that follows this policy is welcome, and the project will not pursue or support legal action over it. Test only equipment and accounts that are yours, or that you have permission to test, and do not access, change, or keep anyone else’s data.