New version: Pantelis23.KernRift v2.8.18

[Pantelis23]

Automated submission. Zip installer with NestedInstallerFiles so both krc and kr land in PATH after one winget install.

Microsoft Reviewers: Open in CodeFlow

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-140-364580-20260423-1

[wingetbot]

Inconsistencies detected in package Pantelis23.KernRift version v2.8.18 based on published version v2.8.17

• Missing property PublisherSupportUrl
• Missing property Author
• Missing property Copyright
• Sequence Tags contains fewer items
• Missing property ReleaseNotes
• Missing property InstallationNotes
• Missing property Commands

[stephengillie]

Automatic Validation ended with:

Installation failed with exit code -1978335187
2026-04-23 18:56:22.233 [FAIL] Installer failed security check. Url: https://github.com/Pantelis23/KernRift/releases/download/v2.8.18/krc-windows-x86_64.zip Result: 0x80004005

Hex	Dec	Inverted Dec	Symbol	Description
80004005	-2147467259	2147500037	E_Fail	Resource missing
8A15002D	-1978335187	2316632109	APPINSTALLER_CLI_ERROR_INSTALLER_SECURITY_CHECK_FAILED	Installer failed security check. Another script should retry this about every 18 hours.

(Automated response - build 1260.)

[Pantelis23]

This is a Windows Defender false positive on the compiler binary (krc.exe) inside the zip. krc is a self-hosted native-code compiler (written in its own source language, bootstraps from a committed binary, emits raw ELF / PE / Mach-O / fat-binary containers from scratch). That combination — executables that construct native machine code and write new executables — trips every generic unsigned-executable heuristic on Defender, especially anything in the Trojan:Win32/Wacatac / Trojan:Win32/Sabsik family.

Evidence this is not malicious:

• Source code is public and fully auditable: https://github.com/Pantelis23/KernRift
• Every byte the release binary was built from is the same source tree: https://github.com/Pantelis23/KernRift/tree/v2.8.18
• The build is reproducible from the committed bootstrap (./build/krc2) → make bootstrap converges on a byte-identical output.
• v2.8.17 of the same package passed Defender under the portable installer type (single krc.exe, same compiler, same byte patterns). v2.8.18 moved to a zip installer with NestedInstallerFiles so winget install Pantelis23.KernRift also installs the fat-binary runner kr.exe. Defender appears to be reacting to the zip-wrapped layout, not the binaries themselves.

I'll submit krc.exe and kr.exe to https://www.microsoft.com/en-us/wdsi/filesubmission for FP analysis. In the meantime, if a maintainer can manually re-run validation or flag for human review that would be appreciated — happy to provide any additional info on how the binaries are produced.

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-140-364580-20260423-2

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-140-364580-20260423-3

[Pantelis23]

Quick status on the current Validation-Installation-Error:

Zip layout is correct. Just verified by downloading the published asset and running unzip -l:

Archive:  krc-windows-x86_64.zip
  1288704  2026-04-23 21:48   krc.exe
    18432  2026-04-23 21:48   kr.exe

Both nested exes are at the archive root, matching the manifest's RelativeFilePath: krc.exe and RelativeFilePath: kr.exe. SHA256 matches the manifest's InstallerSha256.

The krc.exe bytes inside this zip are the same binaries from v2.8.17 which passed validation and was accepted into winget-pkgs on 2026-04-21. The only thing that changed in v2.8.18 is the packaging — v2.8.17 shipped krc.exe directly as portable; v2.8.18 ships a zip with two portable binaries (krc and kr) via NestedInstallerFiles so a single winget install Pantelis23.KernRift installs both tools.

Our hypothesis: the Defender / SmartScreen scan path is different for a zip-wrapped portable installer than a direct-exe portable installer, and the zip context is re-triggering the generic heuristic on krc.exe even though the bytes are identical to the already-approved v2.8.17 asset.

Actions I've taken:

• Submitted both krc-windows-x86_64.exe and kr-windows-x86_64.exe to the WDSI false-positive analysis portal (two days ago).
• Zip asset bytes are reproducible from the public source at commit ad24bb5 via the release workflow in .github/workflows/release.yml.

If a maintainer can flag this for human review alongside the earlier v2.8.17 approval, that would unblock the PR. Happy to provide further info (minisign, build reproduction steps, etc.) on request.

[stephengillie]

Automatic Validation ended with:

Installation failed with exit code -1978335187
2026-04-23 17:42:32.018 [FAIL] Installer failed security check. Url: https://github.com/Pantelis23/KernRift/releases/download/v2.8.18/krc-windows-x86_64.zip Result: 0x80004005

Hex	Dec	Inverted Dec	Symbol	Description
80004005	-2147467259	2147500037	E_Fail	Resource missing
8A15002D	-1978335187	2316632109	APPINSTALLER_CLI_ERROR_INSTALLER_SECURITY_CHECK_FAILED	Installer failed security check. Another script should retry this about every 18 hours.

(Automated response - build 1267.)

[Pantelis23]

This is SmartScreen failing the reputation check on a fresh unsigned release. I've submitted the binary to Microsoft for analysis — reputation usually clears within 24-72 hours. The retry logic mentioned in your error should pick it up once that goes through.

[stephengillie]

@wingetbot run

[wingetbot]

Validation Pipeline Run WinGetSvc-Validation-140-364580-20260424-2

[wingetbot]

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