qttune

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.

The repository hosts all interim development versions; commits between releases are public in the main and dev branches (https://github.com/erickramer42/qttune/commits/main). Work since the v0.3.0 release — ABI changes, test infrastructure, the QML test suite — is committed incrementally with no release gating.

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

Each release carries a semantic version tag in the repository (https://github.com/erickramer42/qttune/tags — v0.1.0, v0.2.0, v0.3.0), and every build embeds the version via a generated header from the CMake project version, so binaries identify their own version too. Interim versions are uniquely identified by git commit IDs.

Each release is identified by an annotated git tag in the repository: v0.1.0, v0.2.0, v0.3.0 (https://github.com/erickramer42/qttune/tags).

Each release ships human-readable release notes published through GitHub Releases, summarizing major changes, breaking changes, and known issues so users can assess upgrade impact:

https://github.com/erickramer42/qttune/releases
https://github.com/erickramer42/qttune/releases/tag/v0.3.0

Notes are organized by subsystem (Core, Bridge, J2534 transport, UI) with a dedicated breaking-changes table for releases with ABI changes. For example, v0.3.0's notes call out the renaming of the ecuio_* C ABI prefix to qttune_* and the changed decode() signature, so downstream integrators know to update their code before upgrading.

No publicly known vulnerabilities have been reported for QtTune's project results. No CVEs or similar identifiers have ever been assigned to QtTune code, so there were no fixed vulnerabilities to identify in the v0.1.0, v0.2.0, or v0.3.0 release notes. If one is ever reported, it will be addressed through the project's security policy (https://github.com/erickramer42/qttune/blob/main/SECURITY.md) and noted in the corresponding GitHub release (https://github.com/erickramer42/qttune/releases).

Non-trivial SECURITY[.md] file found file in repository: https://github.com/erickramer42/qttune/blob/main/SECURITY.md. [osps_do_02_01]

GitHub's issue tracker is used for tracking individual issues: https://github.com/erickramer42/qttune/issues

The GitHub issue tracker (https://github.com/erickramer42/qttune/issues) has received no open bug reports from external users in this period; the tracker is monitored and the README directs bug reports there, so any submitted report would be acknowledged.

No enhancement requests from external users have been filed in this period (https://github.com/erickramer42/qttune/issues?q=is%3Aissue+is%3Aopen). The project is actively developing — the roadmap in STATUS.md tracks planned enhancements, and requests directed to the tracker are discussed and answered, whether accepted, deferred to the roadmap, or declined.

The GitHub issue tracker permanently archives all reports and responses, searchable including closed issues: https://github.com/erickramer42/qttune/issues?q=is%3Aissue

The vulnerability reporting process is published in SECURITY.md: https://github.com/erickramer42/qttune/blob/main/SECURITY.md. Reports go to the project's security contact and are coordinated privately before disclosure.

Private vulnerability reports are submitted through GitHub Security Advisories, as documented in SECURITY.md (https://github.com/erickramer42/qttune/blob/main/SECURITY.md): reporters use the private advisory form (https://github.com/erickramer42/qttune/security/advisories/new), which is transmitted over HTTPS and visible only to maintainers until disclosure. The policy states acknowledgment within 7 days, a status update within 30, and public disclosure after mitigation.

No vulnerability reports have been received in the last 6 months, so this criterion is not applicable. The security policy (https://github.com/erickramer42/qttune/blob/main/SECURITY.md) commits to acknowledging reports within 7 days, which meets the 14-day requirement should reports arrive.

Non-trivial build file in repository: https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt.

Non-trivial build file in repository: https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt.

Built with FLOSS tools throughout: CMake, GCC/Clang, and Qt 6 (LGPL, per the README's license section). CI builds and tests the full application on Linux using only free software (https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml); MSVC is supported for Windows convenience but is not required. Core-only and sanitizer builds run under GCC with no proprietary dependencies, and J2534 hardware testing uses an in-tree fake vendor DLL.

Multiple automated test suites are released with the project under its MIT license: GoogleTest suites for the core, C ABI, bridge and J2534 stack (including an in-tree fake vendor DLL), Qt Quick Test suites for the QML, and libFuzzer harnesses. The README documents how to build and run them (cmake && ctest, https://github.com/erickramer42/qttune#build); detailed per-suite commands and the test tiers are in docs/testing.md (https://github.com/erickramer42/qttune/blob/main/docs/testing.md) and docs/development.md. CI runs the suites on Linux, Windows and macOS on every push (https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml).

The test suites are invoked with ctest, the standard test runner for the CMake ecosystem, as documented in the README (https://github.com/erickkramer42/qttune#build — "ctest --test-dir build") and used by CI on all platforms. Individual suites can also be run by filter (ctest -R "J2534Routing|QmlTest"), documented in docs/development.md.

Test coverage spans every tier of the code: unit suites cover the core library, decoding, the C ABI and the bridge (headless); a harness tier drives the full J2534 stack against an in-tree fake vendor DLL both in-process and through the cross-architecture surrogate; QML suites run the application's pages against a real bridge; libFuzzer harnesses sweep the decoder's and set-validator's input spaces. The scope of each suite and what is deliberately left to manual, hardware-verified tiers (BENCH/Vehicle) is documented in docs/testing.md (https://github.com/erickramer42/qttune/blob/main/docs/testing.md). 271 ctest cases run in CI on Linux, Windows and macOS.

Continuous integration via GitHub Actions: every push to main/dev and every pull request builds and runs the full test suites on Linux, Windows and macOS, runs the core under AddressSanitizer/UBSanitizer, cross-builds for Android and iOS, runs the libFuzzer harnesses, and on pull requests launches the app in the iOS Simulator to verify it runs. The workflow is at https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml.

The project has an explicit policy that major new functionality is tested: CONTRIBUTING.md requires each change to be tested at the appropriate tier and documents the tiers (https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md); additionally, every source file carries a "Testing:" header stating how it is verified, and CI runs the suites on every push and pull request (https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml).

Recent major changes each shipped with automated tests in the same change: the QML test suites added 4 new ctest suites (267 → 271 cases); libFuzzer harnesses were added alongside the fuzzing infrastructure; session recording landed with BridgeTest.Recording* tests; validation and signal-layout changes landed with named test cases in the same commits (see docs/engineering-log.md, https://github.com/erickramer42/qttune/blob/main/docs/engineering-log.md, and the per-commit test additions in the commit history).

The testing policy for changes is documented in CONTRIBUTING.md, the project's instructions for contributions (https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md): it requires tests at the appropriate tier for each change, defines the tiers, and states that pull requests failing CI are not merged.

Compiler warnings are enabled for every first-party target via a shared CMake function (qttune_enable_warnings), and the project builds clean at the highest warning level on MSVC — warnings are treated as failures. Additionally, CodeQL static analysis runs in CI. See https://github.com/erickramer42/qttune — the README's Engineering highlights note zero-warning builds, and the build configuration is documented in docs/development.md.

Warnings are addressed by policy: every first-party target builds with warnings enabled and the build is kept at zero warnings (documented in STATUS.md and the README's engineering highlights, https://github.com/erickramer42/qttune). The sole compiler suppression is a documented MSVC pragma for unreachable-code warnings raised inside Qt's own inline headers, noted in the build files as third-party code, not project code.

The project enables warnings for all first-party targets (via qttune_enable_warnings()) and keeps builds clean at zero warnings on MSVC, as documented in STATUS.md and the README. The sole exception is a documented MSVC pragma suppressing C4702 (unreachable code) inside Qt's own inline headers — a vendor-supplied third party that the project cannot modify, noted as such in the build configuration. This is maximal strictness given the external dependency.

The sole developer is the initiator and primary developer of the project. Secure design principles are evidenced in the project's architecture and record: allowlist input validation at every boundary (URI grammar accepts exactly two schemes; the signal-set validator accepts exactly what the decoder decodes; reserved bytes must be zero), fail-safe read-only defaults, an isolated single-threaded x86 surrogate process limiting the attack surface of untrusted vendor DLLs (behind a fingerprint check refusing ABI-mismatched builds), least-privilege CI with pinned actions, and open design via ADRs documenting every security-relevant decision (https://github.com/erickramer42/qttune/tree/main/docs/adr).

The developer's awareness of common vulnerability classes is evidenced by project-wide mitigations: memory-safety errors are countered by AddressSanitizer/UBSanitizer/LeakSanitizer runs in CI and libFuzzer harnesses over the decoder and validator (including truncated-input and determinism checks); buffer bounds are enforced by design (bounded frame sizes, backpressure caps — ADR-0003); untrusted input is validated with allowlists (the validator accepts exactly what the decoder decodes); untrusted vendor code runs in an isolated single-threaded surrogate process behind an ABI fingerprint check; and information-exposure risks are countered by a documented personal-data scrubbing policy for session logs. Fuzzing setup and sanitizer jobs are visible in https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml and docs/adr/.

The software uses cryptography minimally and only standard published primitives: a standard cryptographic hash (via CMake's file hashing) for the surrogate ABI fingerprint, and the Windows CSPRNG (BCryptGenRandom) for generating unpredictable named-pipe identifiers. No proprietary or unpublished algorithms are used, and no other cryptographic protocols (TLS, key exchange, signatures) are employed. See the surrogate design in docs/adr/0008 (https://github.com/erickramer42/qttune/blob/main/docs/adr).

QtTune's purpose is not cryptographic, and it implements no cryptography itself. The only cryptographic operations — random pipe-name generation and header hashing for the surrogate fingerprint — call on platform and build-system facilities designed for the purpose (Windows BCryptGenRandom, CMake's file hashing), rather than reimplementing primitives in project code. See https://github.com/erickramer42/qttune/tree/main/docs/adr for the surrogate design that uses them.

The project implements no cryptography itself and uses only platform/build-system facilities designed for the purpose: CMake (FLOSS, BSD-licensed) for header hashing and the Windows BCrypt API for random generation. Equivalent FLOSS libraries exist for either operation (e.g., OpenSSL/libcrypto), so no proprietary-only cryptography is required.

The only cryptographic security mechanism in the software is a hash used for the surrogate ABI fingerprint, computed with SHA-256 (256 bits, exceeding the 224-bit NIST 2030 minimum for hashes) via CMake's file hashing. There are no symmetric, asymmetric, or key-agreement parameters anywhere in the software, so no smaller keylengths exist to disable. Random generation uses the OS CSPRNG (BCryptGenRandom), which does not involve configurable key lengths.

No cryptographic mechanisms in the software use broken algorithms. The only cryptographic operations are SHA-256 (for the surrogate ABI fingerprint, via CMake's hashing) and the Windows CSPRNG BCryptGenRandom — both current, non-deprecated standards. The software implements no encrypted protocols requiring legacy algorithm use for interoperability: its IPC is a local named pipe with no cipher, and J2534 is a driver-interface standard, not a cryptographic protocol.

No security mechanism in the software depends on algorithms with known weaknesses. The only cryptographic operations are SHA-256 for the surrogate ABI fingerprint and the Windows CSPRNG (BCryptGenRandom); no cipher modes are used, as the software implements no encrypted protocols.

Not applicable: the software implements no key agreement protocol and uses no long-term keys. Its only cryptographic operations are a build-time hash (surrogate ABI fingerprint) and the OS CSPRNG for random identifiers; no session keys are negotiated.

Not applicable: the software performs no user authentication and stores no passwords. The SECURITY.md policy documents that no credentials are stored (https://github.com/erickramer42/qttune/blob/main/SECURITY.md).

The only cryptographic randomness the software generates — unpredictable identifiers for the surrogate's private named pipe — uses the Windows CSPRNG BCryptGenRandom (a DRBG conforming to NIST SP 800-90A), not any insecure generator. No other cryptographic keys or nonces are generated. See the surrogate design in docs/adr/ (https://github.com/erickramer42/qttune/tree/main/docs/adr).

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The build and release process retrieves no cryptographic hashes over HTTP (or at all): Qt is supplied as a local prerequisite, CI fetches from GitHub over HTTPS, and GitHub Actions are pinned by full commit hash. No unsigned-over-http hash verification step exists in the workflow (https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml).

No publicly known vulnerabilities exist for the project: it has no CVEs, no published security advisories, and no publicly reported vulnerabilities (see https://github.com/erickramer42/qttune/security/advisories — none published). The project runs CodeQL code scanning in CI and fuzzing, which surface issues internally before publication; no external vulnerability reports have been received (per the project's security policy, https://github.com/erickramer42/qttune/blob/main/SECURITY.md).

No critical vulnerabilities have been reported or disclosed. The security policy commits to acknowledging reports within 7 days and providing remediation status within 30 (https://github.com/erickramer42/qttune/blob/main/SECURITY.md), and the project's track record on identified security-relevant defects — e.g., the surrogate ABI-mismatch issue (Known Issue #19) — shows fixes landing within days of identification.

No credentials are used by the project (documented in SECURITY.md), and public repositories contain no working private credentials: CI uses GitHub's ephemeral per-run tokens with least privilege, all Actions are pinned by commit hash, and the repository's history contains no credential patterns (verified by the project's secret-scanning tooling and CI configuration — https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml).

CodeQL static analysis

CodeQL, the static analysis tool used, is specifically a vulnerability-focused analyzer: its C/C++ query suites target common vulnerability classes including memory corruption, use-after-free, integer overflow, and injection paths. Alerts surface at https://github.com/erickramer42/qttune/security/code-scanning.

No medium-or-higher severity findings have been confirmed by CodeQL static analysis: the code scanning alert list is empty (https://github.com/erickramer42/qttune/security/code-scanning). Any alerts that do arise are gated by CI and resolved before merging, as pull requests are not merged with failing checks.

CodeQL static analysis runs on every push to the repository and on every pull request (see the code-scanning workflow in .github/workflows/ and alerts at https://github.com/erickramer42/qttune/security/code-scanning), exceeding the suggested daily cadence. Sanitizer builds (ASan/UBSan) similarly run on every push.

Dynamic analysis is applied continuously: libFuzzer harnesses fuzz the signal decoder and set validator with varying inputs under AddressSanitizer/UndefinedBehaviorSanitizer (CI fuzz job, https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml), sanitizer builds execute the full 271-case test suite, and the J2534 harness tier drives the full stack against a fake vendor DLL programmed with faulty behavior (timeouts, failures) to exercise error paths.

The software is C/C++, and the project routinely combines fuzzing with memory-safety detection: the libFuzzer harnesses run under AddressSanitizer and UndefinedBehaviorSanitizer in CI on every push (https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml), and a dedicated CI job additionally runs the entire test suite under ASan/UBSan/LeakSanitizer. Both mechanisms are exercised continuously, not ad hoc.

Dynamic analysis runs with assertions enabled: CI test, sanitizer and fuzzing jobs build the Debug configuration, enabling C assertions, and the fuzz harnesses themselves assert invariants (determinism, output contracts, return-code ranges) that fire during fuzzing. Release builds compile with NDEBUG, so the assertions are not carried into production binaries.

Dynamic analysis (fuzzing under ASan/UBSan, plus sanitizer runs of the full test suite) runs continuously in CI and has confirmed no medium-or-higher severity vulnerabilities. No findings from these tools remain unfixed; e.g., the one notable integrity defect identified (surrogate ABI mismatch, Known Issue #19) was fixed and its issue closed within the same development cycle.