Security
The repository holds a single copy of this document: both languages of this site point at the same text.
{% raw %}
Reporting a vulnerability🔗
Do not open a public issue. Use GitHub's private reporting instead: Security → Report a vulnerability on the repository. The thread is private between you and the maintainers until an advisory is published, and it keeps the report, the fix and the disclosure in one place.
Expect an acknowledgement within a few days. If you have had no reply after a week, say so on the same thread — a missed notification is more likely than a decision not to answer.
What is in scope🔗
Crabster generates code, so a vulnerability can sit on either side of that line and the two are not equally severe:
- In the generated code — a template that produces an injectable query, a
default that leaves an endpoint open, a secret that reaches a log. These are
the serious ones: the code is copied into other people's projects, and a
project generated last month does not get a fix by upgrading a dependency.
It has to be carried across with
crabster upgrade. - In the generator itself — a
.cdlor a blueprint that makes Crabster write outside the directory it was pointed at, or run something it was not asked to. Blueprints are code and are trusted as such: a blueprint you did not write is a program you did not read.
What is not🔗
- Vulnerabilities in dependencies of a generated project, unless Crabster
pins the vulnerable version. The generator's own CI audits its dependencies;
a generated project audits its own, and its
Cargo.tomlis yours to change. - Anything that requires the attacker to already be able to run code as the
user running
crabster. - A generated project deployed with its example configuration.
.env.exampleis an example, and thedevprofile refuses to be anything else: the development JWT key is rejected outside it, on purpose.
Supported versions🔗
Before 1.0, only the latest published version is supported. Fixes go out as a new release rather than as a patch to an older line. {% endraw %}