Reports are accepted for 1.2.0 and above; the fix itself ships on the
latest release of @geml/geml, so an upgrade is how you receive it. Releases
below 1.2 predate the hardening work described under Scope notes and are not
supported — please upgrade rather than report against them.
| Version | Supported |
|---|---|
| ≥ 1.2 | ✓ — report it; the fix ships on latest |
| < 1.2 | ✗ — please upgrade |
(Stated as a range on purpose: an enumeration of minors goes stale on every release, and a version missing from it reads as unsupported when it is not.)
Please do not open a public issue for security problems.
Report privately via GitHub Security Advisories: on the repository page, Security → Report a vulnerability. This reaches the maintainer directly and keeps the report confidential until a fix is released.
What to include: the affected component (parser, CLI, viewer extension, GitHub
Action, editor integrations), a minimal reproducing input (a .geml /
.gemlhistory snippet or CLI invocation), and the impact you believe it has.
- Acknowledgement within 72 hours.
- Assessment and fix plan within 7 days for confirmed issues.
- Fixes ship as a patch release with the advisory credited to the reporter (unless you prefer otherwise). Coordinated disclosure: we ask that you hold publication until the release is out, and we will not sit on a fix.
GEML processors treat documents as data, never code: code blocks are
never executed, an embed block's target is loaded but never executed, and
diagram bodies are
passed to external renderers verbatim. Reports about untrusted-document
handling (path traversal via cross-document references, resource loading in
rendered HTML, ReDoS in the parser, recipe/CLI injection) are very much in
scope — this project has shipped dedicated hardening releases (1.2.1, 1.2.2)
for exactly that class of issue.