Follow-up to #16, which #38 closed. The workflow side is finished and merged; the WinGet listing itself is not live yet, because the first manual submission is stuck. This issue exists so that state is written down rather than remembered.
Where things stand
Nothing in this repository is waiting on anything. The workflow simply has nothing to do until a release is cut, and cannot succeed until #419679 is merged, because WinGet Releaser needs an existing version in winget-pkgs as the base for the next one.
What is blocking it
08. Installation Validation fails. The neighbouring checks matter as much as the failure:
| Check |
Result |
07. Installers Scan |
pass — the downloaded .exe is not flagged |
08. Installation Validation |
fail — something happened only after installing it |
09. Installer Metadata Validation |
skipped, because 08 is red |
A signature hit would have stopped at 07. So this is a post-install dynamic finding, which is also what winget-pkgs' validation guide says Validation-Defender-Error means.
It does not reproduce locally. Against the exact binary the manifest points at — SHA256 385FF636A922E86809FD34CCDEE71B6095700346B2678E906A32AC3786870F80, matching both the manifest's InstallerSha256 and the published .sha256 — on Windows 11 with Defender platform 4.18.26070.9, engine 1.1.26070.7, signatures 1.457.238.0, real-time protection, IOAV, behaviour monitoring and cloud protection on at CloudBlockLevel High:
- full custom scan clean;
Get-MpThreat and Get-MpThreatDetection both empty
- copied into
%LOCALAPPDATA%\Microsoft\WinGet\Packages\ and executed — no detection
The only Defender event produced was an audit entry for ASR rule 01443614-CD74-433A-B99E-2ECDC07BFC25, block executable files from running unless they meet a prevalence, age, or trusted list criterion. A reputation gate, not a malware verdict — and a new unsigned binary with no install base is what it is built to catch. It fits the 07-green/08-red shape, but it is a hypothesis: the validation VM's configuration is not visible from outside and its logs are not public.
A comment with all of the above is posted on the pull request, asking what the detection actually was. As of 2026-08-19 there has been no reply.
Next steps, depending on what comes back
- They name a real signature or behavioural detection → submit the binary for false-positive analysis at https://www.microsoft.com/wdsi/filesubmission and put the submission ID on the pull request.
- It is the prevalence gate → nothing to fix in the code. Ask what they need to proceed.
- No reply for a couple of weeks → a polite bump on the pull request.
- The pull request gets closed → rebuild and resubmit by hand:
./scripts/winget-manifest.ps1 <version>, then copy target/winget/manifests/ into the fork and open a new New package: SecretLUL.WinMedic version <version> pull request. docs/winget.md has the walkthrough.
Once #419679 is merged
Every later release submits itself. Worth confirming once on the next release that the winget job in release.yml actually opens a pull request, and that winget install SecretLUL.WinMedic resolves afterwards. A version that shipped in the meantime can be caught up with the Run workflow button on winget.yml, which takes a tag.
The durable fix
If this is prevalence-based, it will recur for as long as WinMedic ships unsigned — and it is the same root cause as the SmartScreen warning that motivated #16 in the first place. Code signing (a certificate, or Azure Trusted Signing) retires both. Out of scope here; worth its own issue if it becomes a recurring cost.
Follow-up to #16, which #38 closed. The workflow side is finished and merged; the WinGet listing itself is not live yet, because the first manual submission is stuck. This issue exists so that state is written down rather than remembered.
Where things stand
winget.yml+release.ymlwiring91c383f)WINGET_TOKENrepository secretlicense/clagreenValidation-Defender-Error,Needs-AttentionNothing in this repository is waiting on anything. The workflow simply has nothing to do until a release is cut, and cannot succeed until #419679 is merged, because WinGet Releaser needs an existing version in winget-pkgs as the base for the next one.
What is blocking it
08. Installation Validationfails. The neighbouring checks matter as much as the failure:07. Installers Scan.exeis not flagged08. Installation Validation09. Installer Metadata ValidationA signature hit would have stopped at 07. So this is a post-install dynamic finding, which is also what winget-pkgs' validation guide says
Validation-Defender-Errormeans.It does not reproduce locally. Against the exact binary the manifest points at — SHA256
385FF636A922E86809FD34CCDEE71B6095700346B2678E906A32AC3786870F80, matching both the manifest'sInstallerSha256and the published.sha256— on Windows 11 with Defender platform 4.18.26070.9, engine 1.1.26070.7, signatures 1.457.238.0, real-time protection, IOAV, behaviour monitoring and cloud protection on atCloudBlockLevelHigh:Get-MpThreatandGet-MpThreatDetectionboth empty%LOCALAPPDATA%\Microsoft\WinGet\Packages\and executed — no detectionThe only Defender event produced was an audit entry for ASR rule
01443614-CD74-433A-B99E-2ECDC07BFC25, block executable files from running unless they meet a prevalence, age, or trusted list criterion. A reputation gate, not a malware verdict — and a new unsigned binary with no install base is what it is built to catch. It fits the 07-green/08-red shape, but it is a hypothesis: the validation VM's configuration is not visible from outside and its logs are not public.A comment with all of the above is posted on the pull request, asking what the detection actually was. As of 2026-08-19 there has been no reply.
Next steps, depending on what comes back
./scripts/winget-manifest.ps1 <version>, then copytarget/winget/manifests/into the fork and open a newNew package: SecretLUL.WinMedic version <version>pull request.docs/winget.mdhas the walkthrough.Once #419679 is merged
Every later release submits itself. Worth confirming once on the next release that the
wingetjob inrelease.ymlactually opens a pull request, and thatwinget install SecretLUL.WinMedicresolves afterwards. A version that shipped in the meantime can be caught up with the Run workflow button onwinget.yml, which takes a tag.The durable fix
If this is prevalence-based, it will recur for as long as WinMedic ships unsigned — and it is the same root cause as the SmartScreen warning that motivated #16 in the first place. Code signing (a certificate, or Azure Trusted Signing) retires both. Out of scope here; worth its own issue if it becomes a recurring cost.