New version: M-Igashi.headroom version 1.7.2

[M-Igashi]

New version: M-Igashi.headroom version 1.7.2

• Update mp3rgain to 2.0.3
• Update console to 0.16, indicatif to 0.18, and other dependency updates
• Internal code simplification

Microsoft Reviewers: Open in CodeFlow

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-136-350443-20260320-1

[stephengillie]

Manual Validation ended with:

2026-03-20 11:53:41.481 [FAIL] Installer failed security check. Url: https://github.com/M-Igashi/headroom/releases/download/v1.7.2/headroom-v1.7.2-windows-x86_64.zip Result: 0x80004005
Detection: Trojan:Win32/Sprisky.U!cl
Defender Security Intelligence version: 1.445.591.0

Hex	Dec	Inverted Dec	Symbol	Description
80004005	-2147467259	2147500037	E_Fail	Resource missing

(Automated response - build 1237.)

[M-Igashi]

False Positive: Trojan:Win32/Sprisky.U!cl

This is a false positive detection. Here is the evidence:

1. Built from source by GitHub Actions on windows-latest

The binary was compiled from Rust source code entirely within GitHub Actions CI:

• Release workflow run: https://github.com/M-Igashi/headroom/actions/runs/23346236635
• Windows build job (succeeded): https://github.com/M-Igashi/headroom/actions/runs/23346236635/job/67912234337
• Build steps: actions/checkout → dtolnay/rust-toolchain (stable) → cargo build --release
• No post-processing or obfuscation — the .exe is a standard Rust release binary packaged into a .zip

2. Fully open-source and auditable

• Source code: https://github.com/M-Igashi/headroom (MIT license)
• Release workflow definition: https://github.com/M-Igashi/headroom/blob/main/.github/workflows/release.yml
• The project is a simple CLI audio loudness analyzer — no network activity, no system modification, no persistence

3. Rust binaries are known to trigger heuristic false positives

Rust's standard library statically links system functionality (thread management, panic handling, memory allocation) which can resemble patterns flagged by heuristic scanners. This is a well-documented issue in the Rust community.

Action taken

I have submitted the installer to Microsoft Defender for analysis via https://www.microsoft.com/en-us/wdsi/filesubmission as a false positive.

Request

Could you please re-run the validation once the Defender definitions are updated? Thank you.

[stephengillie]

@wingetbot run

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-136-350443-20260320-2

[stephengillie]

Manual Validation ended with:

2026-03-20 15:39:30.347 [FAIL] Installer failed security check. Url: https://github.com/M-Igashi/headroom/releases/download/v1.7.2/headroom-v1.7.2-windows-x86_64.zip Result: 0x80004005
Detection: Trojan:Script/Wacatac.H!ml
Defender Security Intelligence version: 1.445.591.0

Hex	Dec	Inverted Dec	Symbol	Description
80004005	-2147467259	2147500037	E_Fail	Resource missing

(Automated response - build 1237.)

[M-Igashi]

This is a false positive. The detection name changed between validation runs (Trojan:Win32/Sprisky.U!cl → Trojan:Script/Wacatac.H!ml), which is a strong indicator of heuristic-based false detection rather than actual malware.

This binary is a standard Rust CLI tool built by GitHub Actions CI with no post-processing. The source code, build workflow, and build logs are fully transparent:

• Source: https://github.com/M-Igashi/headroom
• Build workflow: https://github.com/M-Igashi/headroom/blob/main/.github/workflows/release.yml
• Build log: https://github.com/M-Igashi/headroom/actions/runs/23346236635

I have submitted the file to Microsoft Security Intelligence for analysis (Submission ID: 7ae605d9-e619-4272-a30e-27ae15cff8a9). Once Microsoft confirms the false positive and updates their definitions, I will request re-validation.

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-136-350443-20260321-1

[M-Igashi]

Thank you for re-running the validation, @stephengillie.

The security check appears to have passed this time, but the validation now fails with an installation error. Could you share the detailed installation log so I can investigate the root cause?

Possible causes I'm considering:

1. Defender real-time protection may still be blocking the binary at install time (even though the scan step passed), since the false positive submission is still under review by Microsoft.
2. FFmpeg dependency — the manifest declares Gyan.FFmpeg as a package dependency. If the validation environment doesn't have FFmpeg installed, the portable exe may fail a runtime check.

Any details from the installation log would be very helpful. Thanks!

[stephengillie]

@wingetbot run

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-136-350443-20260323-1

[wingetbot]

Publish pipeline succeeded for this Pull Request. Once you refresh your index, this change should be present.