stackchan-atoms3r-gateway

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Work lands on main between releases and is public immediately. Branch protection requires a pull request, so intermediate versions are visible as PR branches and merge commits rather than appearing only at a release.

Repository on GitHub, which uses git. git is distributed.

Every release carries a unique version. VersionPrefix in src/sdk/Directory.Build.props is the single source, and eng/check-version.ps1 fails the build when the tag, that property and the central package entries disagree.

Semantic Versioning. The 0.x line is pre-release and says so in the README and the CHANGELOG; from 1.0.0 the public API follows SemVer. All eight packages move together, so a version identifies one tested combination.

Releases are tagged v<version>, and a ruleset makes v* tags immutable, so a published version cannot be repointed at different code. https://github.com/kkdev92/stackchan-atoms3r-gateway/tags

Non-trivial release notes file in repository: https://github.com/kkdev92/stackchan-atoms3r-gateway/blob/main/CHANGELOG.md.

No vulnerability has been fixed in this project yet. When one is, the CHANGELOG entry will name it; the file already follows Keep a Changelog, which has the section for it. https://github.com/kkdev92/stackchan-atoms3r-gateway/blob/main/CHANGELOG.md

Non-trivial SECURITY[.md] file found file in repository: https://github.com/kkdev92/stackchan-atoms3r-gateway/blob/main/SECURITY.md. [osps_do_02_01]

https://github.com/kkdev92/stackchan-atoms3r-gateway/issues

The project is new and every issue opened so far has had a response. The README states the support policy - a personal project, best-effort - so a reporter knows what to expect rather than guessing from silence.

The README states the support policy plainly: a personal project maintained in spare time, best-effort, and releases may be slow. Enhancement requests get an answer even when the answer is no.

The full issue and pull request history is public and searchable on GitHub. https://github.com/kkdev92/stackchan-atoms3r-gateway/issues?q=is%3Aissue

SECURITY.md gives the reporting process, the threat model, and what is in and out of scope. https://github.com/kkdev92/stackchan-atoms3r-gateway/blob/main/SECURITY.md

GitHub private vulnerability reporting is enabled, so a report can be made without public disclosure first, and SECURITY.md links to the advisory form with an email address as a fallback. https://github.com/kkdev92/stackchan-atoms3r-gateway/security/advisories/new

SECURITY.md sets the expectation: an acknowledgment and an initial assessment once the report has been reviewed, with remediation timing driven by impact. No report has been received yet. https://github.com/kkdev92/stackchan-atoms3r-gateway/blob/main/SECURITY.md

dotnet build, from a pinned SDK: global.json fixes 10.0.303 with rollForward latestPatch, so the toolchain is the same for a contributor and for CI.

The .NET SDK and MSBuild, both freely available at no cost for every supported platform.

The .NET SDK is MIT-licensed, and the build runs on both Windows and Linux in CI, so it does not depend on a proprietary platform.

499 automated tests: 378 for the SDK and 121 for the reference host, across ten test projects. eng/build-all.ps1 runs the SDK tests, packs the packages, then runs the host tests against the packed packages rather than against project references.

pwsh eng/build-all.ps1 - one command, documented at the top of CONTRIBUTING.md.

The 499 tests cover the wire contract byte for byte (13 conformance checks plus mutation tests that verify each check reports its own violation), turn orchestration including timeout, cancellation, admission and eviction, each provider and capability, the package boundaries by reflection, and the reference host end to end against the packed packages. Coverage is not reported as a percentage, and the deliberate gap is named instead: hardware behaviour - microphone, speaker, expression and emergency stop - which is verified on a real device outside CI. docs/architecture.md#tests

ci.yml runs format, build, the full test chain and pack on every push and every pull request, on both windows-latest and ubuntu-latest. Those checks are required, so they block a merge until they pass. https://github.com/kkdev92/stackchan-atoms3r-gateway/actions/workflows/ci.yml

CONTRIBUTING.md requires tests with a change, and the design requirements it lists are themselves enforced by tests (ArchitectureInvariantTests, AppCompositionTests), so a change that breaks one fails the build instead of waiting for a reviewer to notice.

Each functional change so far arrived with tests. The four defects found during hardware verification were each reproduced by a failing test before being fixed.

CONTRIBUTING.md states the requirement, under Tests and Test expectations. https://github.com/kkdev92/stackchan-atoms3r-gateway/blob/main/CONTRIBUTING.md

TreatWarningsAsErrors is true and AnalysisLevel is latest-recommended in Directory.Build.props, so a warning fails the build. EnforceCodeStyleInBuild applies the .editorconfig rules at compile time as well.

Warnings are errors, so none can remain in a build that succeeds, and the build succeeds on both CI platforms.

Nullable reference types are enabled, warnings are errors, AnalysisLevel is latest-recommended, and NuGetAudit runs at mode all - transitive dependencies included - with level low, the lowest threshold available.

The design applies the Saltzer and Schroeder principles that bear on it. Least privilege: each release job holds only what it needs, so the job that builds has no publishing key and the job that publishes checks out no source; workflow token permissions default to read. Fail-safe defaults: startup refuses to run unauthenticated on a non-loopback address, and a token is mandatory outside fixed-response mode. Economy of mechanism: the runtime has no HTTP or SSE dependency, so the wire format cannot leak into orchestration. Complete mediation: every request is authenticated and size-checked in one place before any streaming starts. Open design: the protocol and the threat model are both public. docs/architecture.md#defenses records each defence and why it is there.

The errors that apply to a device gateway, each with the countermeasure in place. Unauthenticated access: a mandatory token compared with CryptographicOperations.FixedTimeEquals, so comparison time does not depend on which bytes match. Injection through identifiers: the device, boot and conversation headers are length-capped at 128 characters and checked against an ASCII allowlist, and a malformed one is answered 400 before anything else happens. Resource exhaustion from untrusted input: caps on request body, utterance length, downstream response size, concurrent turns and session count, with idle eviction. Untrusted input from a dependency: a downstream response is read under a byte limit rather than buffered whole. Secret leakage through logs: transcripts and replies are logged by length, query strings are stripped from provider logs, and the startup dump prints a secret length instead of its value. Denial of service through an unauthenticated endpoint: the provider health probe is cached so it cannot be used to make the gateway call outward repeatedly.

No bespoke cryptography. The one use is CryptographicOperations.FixedTimeEquals from the .NET base class library, for the constant-time device token comparison.

The .NET base class library provides the primitive; nothing is reimplemented.

The .NET runtime and its cryptography are MIT-licensed.

No keys are generated or negotiated. The device token is a credential minted by the firmware and supplied to the gateway through an environment variable; the gateway only compares it.

No security mechanism depends on a broken algorithm. There is no use of MD4, MD5, single DES, RC4 or Dual_EC_DRBG anywhere in the source; the only cryptographic call is a constant-time byte comparison, which uses no algorithm at all.

No SHA-1, and this project selects no cipher mode. Transport between device and gateway is plain HTTP because the firmware does not implement TLS - a property of the device, stated in the README limitations and in SECURITY.md rather than left for a reader to discover.

The project establishes no cryptographic session of its own. Connections to downstream services use whatever the operator configures; the gateway defaults its own outbound weather call to https.

No passwords and no user accounts. The single credential is a device token supplied through an environment variable and never written to a file, a log or a record.

No random values are generated for a security purpose. The token comes from the firmware, and session identity is the device identifier the device sends.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Nothing is retrieved over http. nuget.config clears inherited sources first, so a machine-level source cannot be added silently; the only remote source is nuget.org over https, and the other is a local folder of packages this repository builds. RestorePackagesWithLockFile is on and the lock files are committed - 296 SHA-512 contentHash entries - so restore verifies every downloaded package against a hash that came from the repository rather than from the network, and a substituted package fails the build. GitHub Actions are pinned by commit SHA rather than by a movable tag. The packages this project publishes are served by nuget.org over https.

No vulnerability has been reported against this project; the first release, 0.1.0, was published on 2026-08-31. A known advisory cannot reach a build either: NuGetAudit runs at mode all, so transitive dependencies are included, at level low, the lowest threshold, and warnings are errors - so any advisory at any severity fails the restore rather than producing a report somebody has to read. Dependabot watches NuGet and GitHub Actions, and CodeQL runs on every push and pull request and weekly. Nothing of medium or higher severity is outstanding; the open cs/log-forging alerts are false positives, explained under static_analysis_fixed, and they were raised this month in any case.

No critical vulnerability has been reported. SECURITY.md commits to an acknowledgment and an initial assessment, with remediation timing driven by impact, and private vulnerability reporting is enabled so a reporter need not disclose publicly to get a fix started. Releasing is deliberately cheap: one tag runs the whole verified chain and publishes all eight packages together, so a fix does not wait on release mechanics.

Secret scanning and push protection are both enabled, so a credential is blocked at the push rather than found later. Tracked configuration ships with empty secret values; the device token and the weather API key are supplied through environment variables or a gitignored local directory only. A test asserts that a capability API key does not reach the logs, and the whole tracked tree was reviewed for credentials before the repository was made public.

Three tools, on every push and every pull request. CodeQL default setup runs the extended query suite over both C# and the workflow definitions, and weekly in addition. The .NET analysers run at latest-recommended on every build with warnings as errors. OpenSSF Scorecard runs as its own workflow and reports into code scanning. https://github.com/kkdev92/stackchan-atoms3r-gateway/security/code-scanning

CodeQL is configured with the extended query suite and the remote threat model, which is the security-focused C# pack rather than the default subset - it is what raises the injection and taint-flow queries this project is currently answering. The .NET analysers add the CA2xxx/CA3xxx/CA5xxx security rules at build time.

An analyser finding cannot be merged at all: the .NET analysers run at latest-recommended with warnings as errors, so it fails the build. CodeQL currently reports thirteen medium-severity cs/log-forging alerts, all on one value - the device identifier written to a structured log field - and they are not exploitable. Every identifier header is checked by DeviceHeaders.IsWellFormed before the request object is constructed: at most 128 characters drawn from the allowlist 0-9 A-Z a-z hyphen underscore dot colon, which excludes CR, LF and every other control character, and a header that fails is answered 400 before it is used. The rejection path itself logs malformed:length rather than the value. CodeQL does not model ContainsAnyExcept over a SearchValues<char> as a sanitiser, so the allowlist is invisible to it. The token, the request body and the user utterance are never logged at all. The five Scorecard alerts are posture observations - no fuzzing, a solo maintainer reviewing their own commits, and the absence of this badge - not vulnerabilities.

On every push and every pull request, and weekly on a schedule in addition.

tools/device-sim drives the real HTTP and SSE surface with inputs the firmware does not produce - malformed requests, an over-long utterance, a mid-stream disconnect, concurrent turns - and each scenario asserts its expected status or protocol result. The reference host is also exercised end to end on real hardware before a release.

C# is memory-safe and this project enables no unsafe code: AllowUnsafeBlocks is set nowhere, so the compiler rejects an unsafe block.

Argument validation runs in release builds rather than being compiled out: public entry points use ArgumentNullException.ThrowIfNull and ArgumentException.ThrowIfNullOrEmpty, and the options for every package are validated at startup with ValidateOnStart, so a misconfiguration fails at boot and not mid-turn.

Every defect found this way was fixed before release. Hardware and simulator verification found four during this cycle - a wire-contract violation, a parser crash, an ineffective setting and a diagnostic gap - and each was reproduced by a failing test before it was fixed.