Real engineers read every report - no Tier-1 ticket triage, no chatbots. Bugs in the SDK, CLI, compiler plugin, or docs go through the form below. Security vulnerabilities get a private channel.
We split security from everything else for one reason: public bug reports get fixed in the open, security reports don’t. If you’re not sure which bucket your report falls in, default to the form. We’ll move it if it needs the private channel.
A crash, a stack trace, a Gradle task that fails, a screen that renders wrong, a CLI command that hangs. Anything reproducible.
Open a bug reportThe docs claim X but the SDK does Y. Either it's a bug or the docs are wrong, either way we want to know.
Open a docs reportSignature bypass, sandbox escape, anything that could harm Ketoy users. Please do not open it here, email us instead.
Email securityNone of this is required - empty reports still get read - but the more of these you include, the faster we get from “received” to “fixed in the next release.”
The SDK version, the Gradle plugin version, and (for CLI bugs) the ketoy CLI version. Run `ketoy version` if you have the CLI.
A one-line description of what should have happened beats a five-paragraph description of the workaround you tried.
Stack trace, build output, KBC error message - whatever the tooling printed. Truncate noise, keep the relevant lines.
A minimal sample is gold, but never required to open a report. If we need one to make progress, we'll ask.
Submissions go directly to engineering. You’ll usually hear back within a business day - worst case, the morning after.
Signature-verification bypass, sandbox escape, capability boundary violation, anything that could compromise Ketoy users - we want to know privately, before it’s on a public tracker. We’ll fix it, ship the patch, and only then write it up.
Include a description of the issue, your reproduction steps, and the affected version. PGP welcome but not required.
