Repository navigation
Windows Application Control blocks Grimp native extension — signed Windows wheels? #319
Description
Hello Grimp maintainers,
We encountered a Windows Application Control block when Import Linter loaded Grimp’s native extension.
Environment
- Windows with Smart App Control enabled
- Python 3.12, Windows x64
- Import Linter 2.14
- Grimp 3.16
Observed error
ImportError: DLL load failed while importing _rustgrimp:
An Application Control policy has blocked this file.
Windows Code Integrity events 3077 and 3033 identified _rustgrimp.cp312-win_amd64.pyd as the blocked file. Its hash and size match the installed package’s RECORD metadata; Windows reports it as unsigned.
We also inspected the published Grimp 3.17 CPython 3.12 Windows x64 wheel after verifying its PyPI SHA-256. Its native extension has no embedded PE certificate table. We have not installed or executed 3.17, so we cannot confirm whether Windows would block that version. Catalog signatures and cloud reputation were not evaluated.
Could you advise whether:
- Publisher-signed Windows wheels are available or planned?
- There is a supported way to use Grimp with Smart App Control enabled that does not require disabling or bypassing Windows protections?
We would like to retain Grimp and our existing architecture contracts. We can provide artifact hashes and sanitized Code Integrity event details if helpful.
Thank you.
Activity
seddonym commentedon Oct 1, 2026
Thanks for raising the issue! I'll look into it.
seddonym commentedon Oct 13, 2026
I've looked a little more into this - my understanding is that while it would be possible to sign the wheels as part of the release process, it may not make much difference in practice as you'd still need to trust me as a maintainer. Probably, the solution lies your end, in allow-listing Grimp as part of your security policy.
I don't know much about this subject so would be open to changing my mind, but as it stands I'm not planning to sign the wheels.