qttune

QtTune is pre-release (v0.1.0–v0.3.0) with no production or widely-used older versions; the current development line supersedes prior tags, as stated in the version support table (https://github.com/erickramer42/qttune/blob/main/SECURITY.md). Upgrade compatibility is managed by design: the public C ABI is append-only so newer cores remain source-compatible with existing consumers, and deliberate breaks are flagged with feat!: commits, the ECUIO_SIGNAL_SET_LAYOUT version guard (https://github.com/erickramer42/qttune/blob/main/docs/adr/0016-signal-definition-layout.md), and documented in ADRs under docs/adr/.

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

QtTune is in pre-release development (v0.1.0–v0.3.0) with no production-deployed versions in the wild. No vulnerability reports have been received and resolved in the last 12 months per the security policy (https://github.com/erickramer42/qttune/blob/main/SECURITY.md). The project has a public reporting channel via GitHub Security Advisories, but as of this assessment date, no CVEs or security advisories have been issued.

SECURITY.md documents the full response process: intake via GitHub Security Advisories (https://github.com/erickramer42/qttune/security/advisories/new), acknowledgment within 7 days and status updates within 30 days, coordinated public disclosure after mitigation, and category-specific response paths distinguishing code-security findings (CVE assignment if severe) from supply-chain, privacy and intentional protocol-analysis behavior. See https://github.com/erickramer42/qttune/blob/main/SECURITY.md.

Coding standards are identified per primary language and required of contributions: LLVM-based .clang-format for C/C++ (with documented deviations), SEI CERT C as the reference for the strict-C ABI headers, Qt's QML Coding Conventions for the front end, and the tree's CMake conventions, with zero-warning builds enforced for every first-party target. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md and https://github.com/erickramer42/qttune/blob/main/.clang-format

The project builds with CMake, which honors the standard environment variables by design: CC/CXX select the compiler and CFLAGS/CXXFLAGS/LDFLAGS are absorbed into the initial CMAKE_<LANG>_FLAGS cache at configure time and applied to every compiler and linker invocation, rather than replaced. The project's own flags (-Wall -Wextra, hardening) are appended per-target via target_compile_options and never overwrite the incoming values. Sanitizer builds (ASan/UBSan) are enabled in CI through CMake options, so distribution hardening and instrumentation features can be turned on without editing the build files. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The build system is CMake with no stripping anywhere in the build: there is no install -s, no --strip linker flag, and no post-build strip step in any target or CI job. Debugging information follows the standard CMake mechanism — -g arrives via CXXFLAGS/CFLAGS or CMAKE_BUILD_TYPE=Debug/RelWithDebInfo and is passed through to every compiler invocation, with no toolchain file or target property overriding it. Sanitizer and fuzz builds in CI compile with full symbol information. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The build uses CMake, which is not a recursive build system: add_subdirectory scopes variables and targets but does not invoke an independent build per directory. CMake generates one unified dependency graph for the whole project, so cross-directory dependencies are expressed accurately — the app target links ecuio-core, tests link both, and the root-level Qt-link check reads ecuio-core's link properties after every subdirectory has been processed, which only works because the graph is global. No recursive make invocation exists anywhere in the tree. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

QtTune is pre-release software with no distributed artifacts: there are no releases, downloads, or packages intended for installation, and per SECURITY.md no supported production versions exist yet. The project distributes only source, built locally by users from the repository, so no commonly-used installation convention applies. Formal installation and packaging (including signed release artifacts) are planned for v1.0 as documented in SECURITY.md. See https://github.com/erickramer42/qttune/blob/main/SECURITY.md

QtTune has no installation system: it is pre-release source-only software with no make install, packaging, or distributed artifacts, so no installation-location convention applies. Users build and run from their own build trees. Packaging with standard conventions is planned for v1.0 (see SECURITY.md's release plans). See https://github.com/erickramer42/qttune/blob/main/SECURITY.md

Potential developers get a documented, quick setup path: CONTRIBUTING.md's "Building" section gives the complete three-command flow (cmake configure with CMAKE_PREFIX_PATH, build, ctest), with exact compiler and CMake minimums stated up front. docs/development.md extends this with platform-specific instructions, including installing Qt via aqtinstall (with the documented workaround), the two-tree Windows layout for the surrogate and fake DLLs, and troubleshooting. Every test tier that can run without real hardware (Unit, Bridge, QML, HARNESS, Fuzzing) executes through the same ctest invocation, so the test environment comes with the standard build. The CI workflows demonstrate the setup is fully automatable: GitHub Actions installs Qt, configures, builds and runs the whole suite on all three desktop platforms from the repository alone. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md and https://github.com/erickramer42/qttune/blob/main/docs/development.md

The project's external dependencies are declared in the build system's computer-processable form: root and per-directory CMakeLists.txt files use find_package(Qt6 6.12 REQUIRED COMPONENTS Core Gui Quick ...) with the required components and minimum version stated, and each first-party target links against the imported targets by name. The compiler/CMake minimums are likewise machine-checked via cmake_minimum_required(VERSION 3.21) and the C++17 standard setting, so a configure step fails loudly and early when a dependency is missing or too old. CI workflows additionally encode the dependency acquisition (Qt via aqtinstall with a pinned version) in executable YAML. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt and https://github.com/erickramer42/qttune/blob/main/app/CMakeLists.txt

The repository monitors external dependencies with Dependabot (.github/dependabot.yml), which performs version and vulnerability monitoring on the dependency surface declared in the repository — GitHub Actions workflows — and opens pull requests when updates or vulnerable versions are detected. GitHub additionally surfaces Dependabot alerts for any dependency in a recognized manifest. The project's runtime dependency surface is deliberately minimal: Qt is a system-provided library rather than a vendored or manifest-pinned component, and the C ABI design keeps convenience copies of third-party code out of the tree. See https://github.com/erickramer42/qttune/blob/main/.github/dependabot.yml

QtTune uses system/provided components rather than bundling them: Qt is resolved via find_package(Qt6) against the user's or distro's Qt installation and linked dynamically (LGPL), with no vendored or forked convenience copies anywhere in the tree. The only externally-maintained components consumed at build/runtime are Qt and the Windows VC redistributable, both obtained from their upstream providers through their standard distribution mechanisms (system Qt packages, aqtinstall in CI, VS redist installer). CI pins Qt's version at acquisition, so updating to a patched Qt release is a one-line change in the workflow file. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The project's technology stack is current throughout: C++17 with CMake 3.21+ targeting Qt 6.12 (the current Qt release line), MSVC 2022+/GCC 10+/Xcode 16+ as minimums — all matching Qt 6's own requirements. No deprecated API usage is apparent, and several documented decisions explicitly chose modern alternatives: UTF-8/UTF-16 conversion via the established pattern in win_utf8 instead of Annex K functions, Win32 registry enumeration via RegOpenKeyExW/RegEnumKeyExW with explicit wide-char forms rather than the legacy ANSI variants, and GetProcAddress-based dynamic resolution instead of deprecated import mechanisms. The build enforces currency mechanically: every first-party target compiles with /W4 or -Wall -Wextra at zero warnings, so deprecation warnings (a standard category in both compilers) cannot accumulate silently. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The project runs its full test suite in CI on every push and pull request via .github/workflows/ci.yml: GitHub Actions builds and runs the ctest suite on Windows, Linux and macOS for each commit to main and each PR, producing pass/fail reports on the Actions run page. Reports detail every test case and outcome per platform. Additional jobs run the Qt-free core-only configuration, sanitizer builds (ASan/UBSan), libFuzzer harnesses, and the iOS Simulator smoke on PRs. The commit history shows CI has been consistently applied since its introduction. See https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml and https://github.com/erickramer42/qttune/actions

Every bug fixed in the last six months receives a regression test as a matter of documented policy: CONTRIBUTING.md's pull-request checklist requires tests for bug fixes, and the project's testing tiers exist to pin bug behavior at the level where it occurred. The closed Known Issues (#21, #25, #26, #31, #32, #33, #34, and others in STATUS.md's history) correspond to test coverage in the suite — e.g., the write-latch behavior (#33's async teardown) is pinned by bridge tests, and the backoff-growth test (BackoffGrowsUnderSustainedHardFailure) exists specifically to prevent the sustained-failure regression from returning. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md

The project has a documented, enforced policy that new functionality requires tests: CONTRIBUTING.md's Testing section states "a change is only done when tested at the right tier" and mandates the appropriate tier per change type — with the strengthened rule that "changes to timing, threading, callbacks or streaming state need at least a Bridge- or HARNESS-tier test even if a unit test passes." Pull requests must describe how the change is tested (the // File/layer: and // Testing: headers every changed file carries), and CI gates merging on a green suite ("A pull request that isn't green on CI won't be merged"). Evidence: https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md

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.

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.

QtTune implements secure design principles through: (1) read-only vehicle interaction by default, eliminating write-side attack surfaces; (2) strict URI scheme validation rejecting unknown transports; (3) append-only C ABI preventing accidental interface mutation; (4) tiered test coverage including libFuzzer harnesses and ASan/UBSan in CI; (5) thread-isolation rules ensuring callbacks cannot block or destroy sessions. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md and https://github.com/erickramer42/qttune/blob/main/SECURITY.md.

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.

QtTune is an ECU reader/logger, not a security library; it performs no encryption or hashing of user data. Vehicle communication uses OBD-II/J2534 standard protocols with no cryptographic layer controlled by the project. Signed release artifacts are noted as future work in SECURITY.md (https://github.com/erickramer42/qttune/blob/main/SECURITY.md), at which point algorithm selection would become relevant.

QtTune processes no authentication credentials or private cryptographic keys. Per SECURITY.md, the project stores no credentials ("currently: none stored"), and vehicle communication via OBD-II/J2534 requires no user authentication. Signed release artifacts are future work noted in SECURITY.md (https://github.com/erickramer42/qttune/blob/main/SECURITY.md), making this criterion inapplicable until then.

QtTune does not support network communications. It communicates locally via J2534 hardware adapters (CAN bus diagnostic protocol) and mock:// transport, not network stacks. All vehicle I/O is direct-to-adapter; no TCP/IP, HTTP, SSH, or similar protocols are used. See https://github.com/erickramer42/qttune/blob/main/docs/j2534.md.

QtTune does not use TLS. All communication is local: J2534 adapter I/O via USB and mock:// in-process transport. No TLS or SSL is involved anywhere in the project.

QtTune does not use TLS for any communications. Vehicle I/O occurs over J2534 hardware adapters (USB-CAN) and mock:// in-process transport; no TLS/SSL certificates are validated or loaded anywhere in the project.

QtTune does not use TLS and sends no HTTP traffic. There are no cookies, HTTP headers, or remote endpoints. All vehicle I/O is local via J2534 hardware adapters and mock:// in-process transport.

QtTune is in pre-release development (v0.1.0–v0.3.0) and distributes no releases intended for widespread use — no binaries, packages, or signed artifacts are published. Per SECURITY.md, signed release artifacts are planned for the v1.0 release (https://github.com/erickramer42/qttune/blob/main/SECURITY.md). Until releases are published, this criterion does not apply.

All external inputs are validated against allowlists before use: transport URIs accept only the enumerated schemes mock:// and j2534://, with all others rejected; frame payloads are limited to the 64-byte CAN FD maximum; numeric fields are range-checked against documented OBD-II parameter limits; and signal identifiers are matched against the enumerated signal definitions, with unknown IDs rejected. Validation order is documented and enforced in the Qt-free core, and the validators are continuously exercised by libFuzzer harnesses in CI. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md (Input validation section) and https://github.com/erickramer42/qttune/blob/main/fuzz/README.md.

All first-party targets compile with compiler hardening: -fstack-protector-strong, -D_FORTIFY_SOURCE=2 (MSVC /GS, /guard:cf) and linker hardening (-Wl,-z,relro -Wl,-z,now) via the shared qttune_enable_warnings function in root CMakeLists.txt. Builds on Windows, Linux and macOS complete with zero warnings. Evidence: https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

QtTune's assurance case is documented at docs/security-assurance.md (https://github.com/erickramer42/qttune/blob/main/docs/security-assurance.md). It identifies the threat model (adversaries: malicious J2534 vendor DLLs, compromised adapters, hostile vehicles, supply-chain compromise; assets: host integrity, vehicle safety, user privacy), marks trust boundaries (adapter→worker, worker→core decode, core→bridge, surrogate parent→child IPC, build→runtime) with the control enforced at each, maps secure design principles to specific implementation evidence (economy of mechanism via read-only Mode-01 operation, fail-safe defaults via strict profile rejection, complete mediation via allowlist input validation, defense in depth via the tiered test matrix with ASan/UBSan and libFuzzer in CI), and counters common implementation weaknesses (buffer overflows via the 64-byte frame cap and sanitizers, use-after-free via closed-before-destroy session lifecycle and callback snapshotting, unsafe deserialization via signal-set validation, dependency risk via Dependabot and pinned actions). Supporting evidence: https://github.com/erickramer42/qttune/blob/main/SECURITY.md and https://github.com/erickramer42/qttune/blob/main/docs/testing.md.

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.

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.