English | 简体中文

Please do not open a public issue for problems that could realistically be abused as a security vulnerability. If a report involves unauthorized claiming, unsafe ownership transfer, credential or secret exposure, insecure recovery behavior, key-handling flaws, record tampering, or any exploit path that others could reuse, report it through the maintainer contact path first.

If you discover a vulnerability, report it privately through the repository owner's available contact channel and include:

• a clear summary
• affected files, devices, host components, or subsystem
• reproduction steps if known
• possible impact
• suggested mitigation if available

Examples include:

• claim or transfer paths that could be abused by an attacker
• device identity checks that can be bypassed or spoofed
• recovery behavior that can be misused as an unauthorized takeover path
• local record tampering that changes ownership meaning
• credential, token, or secret exposure once provisioning exists
• unsafe local or network control paths around steward or device-side flows

The following are generally not security reports and should not be sent through the private vulnerability path:

• generic embedded bugs with no plausible security angle
• incomplete prototype behavior without an exploit path
• missing features that were never promised
• third-party device, board, or radio stack defects
• wiring mistakes, setup mistakes, or damaged parts
• unsupported local modifications
• "it does not work" reports without a credible security impact

Those issues should usually be handled as:

• a normal public bug report
• a Question / Support issue
• or a local debugging task outside project maintenance scope

This repository is an early open project, not a guarantee of correctness for every third-party board, radio module, mobile device, USB bridge, or user-built deployment.

The project security process is intended for vulnerabilities in the repository's own design, code, documented behavior, or supported workflows. It is not intended to triage every failure in:

• third-party hardware quality
• user-built setup quality
• unofficial modifications
• off-spec deployment
• undocumented operating procedures
• unsupported integrations or experiments

At this stage, the repository is in active planning and early implementation. Support is best-effort, and response time may vary.

Please allow time for review and mitigation before publishing detailed exploit steps. Coordinated disclosure is preferred.