Dkompos 1.6.5

Dkompos 1.6.5

Dkompos 1.6.5 upgrades the native audio engine to Symphonia 0.6 while keeping
the release boundary conservative: decoded fidelity is proven against pinned
oracles, transparent-output admission fails closed, and hostile container
lengths are bounded before they can reach the allocator.

Symphonia 0.6 without silent fidelity drift

• The decoder, probe, packet, timing, seek, metadata, chapter, and EOF paths now
  use Symphonia 0.6.0 through one resolved dependency generation.
• Lossless transparent routes are admitted only for FLAC, ALAC, and linear PCM.
  Unknown codecs and ADPCM variants remain on the processed path instead of
  inheriting an unsafe bit-depth assumption.
• MP3 decoded-direct admission uses Symphonia's codec identifier rather than a
  display name that could drift independently of routing policy.
• ALAC source precision is recovered from the standard magic cookie because
  Symphonia's decoded I32 container does not itself identify the original bit
  depth.
• Clean EOF is distinct from truncated input. A damaged WAV, FLAC, or M4A now
  fails as a decode error instead of being accepted as a short successful file.

Deterministic compatibility evidence

The checked-in corpus covers PCM16 WAV, AIFF, and CAF; PCM24 WAV; IMA and
Microsoft ADPCM; FLAC16 and FLAC24; ALAC16; CBR and VBR MP3; AAC in MP4 and
ADTS; and Vorbis in Ogg and Matroska.

Transparent WAV samples are parsed independently of Symphonia and pinned as
canonical SHA-256 streams. AIFF, CAF, FLAC, and ALAC must decode to those exact
samples. The decoded-direct MP3 I32 stream is pinned separately, and every
corpus file must produce non-empty output with zero wrapper-versus-direct
sample mismatches.

Metadata, chapters, and library scanning

• Typed Symphonia metadata is mapped into Dkompos without stringly typed
  fallbacks for track/disc totals, ReplayGain, BPM, musical key, artwork, and
  audiobook fields.
• A focused local RIFF patch retains LIST/INFO metadata that Symphonia 0.6.0
  parses but otherwise drops when constructing its WAVE reader.
• Authored ID3 chapters retain their titles and boundaries. Truly chapterless
  audio still receives the duration-based fallback used by Dkompos audiobooks.
• .mka participates in automatic music discovery. .mkv remains available
  for explicit decoding but is excluded from recursive music scans so video
  extras do not pollute the catalogue.
• Startup scans aggregate imported, unchanged, unreadable, and pruned counts;
  routine candidate probes no longer flood the bounded application log.

Allocation hardening for untrusted media

Symphonia issue #539 reports eight attacker-controlled allocation paths through
the shared ReadBytes::read_boxed_slice{,_exact} helpers, including petabyte
requests that unconditionally terminate a panic = "abort" process.

Dkompos carries a source-audited Symphonia Core patch that caps each boxed read
at 64 MiB and reserves memory fallibly. Oversized values fail with
InvalidData before input is consumed; reservation failure becomes
OutOfMemory instead of a process abort. No enabled Symphonia 0.6 reader
overrides the protected helpers.

The eight reported allocation magnitudes run in isolated child processes under
the optimized release profile. The upstream crafted byte sequences remain
private, so the release proof combines those dynamic boundary tests with a
static audit that every reported format path reaches the guarded methods.

Known constraints

• Symphonia 0.6's ISO-MP4 reader does not expose the authored chapters in the
  migration M4B fixture; Dkompos uses its honest chapterless fallback there.
• A single packet or metadata value above the 64 MiB security budget is
  rejected. This may reject pathological embedded artwork, but it cannot take
  down the application.
• The local Symphonia patches remain until an upstream release provides
  equivalent allocation hardening and RIFF metadata retention.

Qualification

The candidate passed formatting, locked all-target Rust compilation, warnings-
as-errors Clippy, the complete workspace suite, fixture checksum verification,
the 17-file wrapper-parity corpus, release-profile hostile-length tests,
generated UniFFI binding regeneration, an arm64 bridge build, native Swift
compilation/linking, application launch, and clean startup diagnostics.

Hosted full-Xcode XCTest did not execute: GitHub Actions failed before creating
any job steps, and the local machine has Command Line Tools but no XCTest
framework. At the owner's explicit direction, publication proceeded through
the documented local release path. Apple accepted the separately submitted app
and DMG, and both artifacts passed Developer ID signature verification,
stapling, Gatekeeper assessment, and published SHA-256 verification. Hosted
full-Xcode confirmation remains open release debt.