Created with GitHub Copilot assistance.
Relevant area(s)
WinGet CLI
Description of the new feature / enhancement
This is a sub-issue of #6189 for a specific class of PUA detection: encrypted files.
Some legitimate applications include encrypted components as part of their build process (e.g., auto-update clients, license enforcement modules). Detection engines like K7 flag these with generic "File is encrypted!" detections, which triggers ESRP scan blocking in the WinGet Community Repository.
Known examples:
- Trados Studio — IndigoRose TrueUpdate
UpdateClient.dat is encrypted by design during the build process (PR #373424)
- Malwarebytes — K7 encrypted file detection (PR #356473)
Unlike detections for remote access or adware behaviors, an "encrypted file" detection does not indicate malicious intent — it simply means a file within the installer is not readable by the scanning engine. This is a common practice for protecting proprietary update mechanisms and licensing logic.
Proposed approach
Once the parent issue (#6189) design for PUA classes and Group Policy controls is in place, "encrypted file" detections should be one of the first classes considered for an allow-path, given:
- The detection is purely structural (file is encrypted), not behavioral
- The publishers are known and have a history of legitimate submissions
- The encryption is an intentional part of their toolchain (IndigoRose TrueUpdate, etc.)
Related
Proposed technical implementation details
No response
Relevant area(s)
WinGet CLI
Description of the new feature / enhancement
This is a sub-issue of #6189 for a specific class of PUA detection: encrypted files.
Some legitimate applications include encrypted components as part of their build process (e.g., auto-update clients, license enforcement modules). Detection engines like K7 flag these with generic "File is encrypted!" detections, which triggers ESRP scan blocking in the WinGet Community Repository.
Known examples:
UpdateClient.datis encrypted by design during the build process (PR #373424)Unlike detections for remote access or adware behaviors, an "encrypted file" detection does not indicate malicious intent — it simply means a file within the installer is not readable by the scanning engine. This is a common practice for protecting proprietary update mechanisms and licensing logic.
Proposed approach
Once the parent issue (#6189) design for PUA classes and Group Policy controls is in place, "encrypted file" detections should be one of the first classes considered for an allow-path, given:
Related
Proposed technical implementation details
No response