Story: define an official signed Windows installer distribution

[inayayousfi]

Problem

The current release flow publishes a Windows standalone ZIP, but there is no official signed Windows installer story yet.

That leaves a few gaps:

• Windows Defender SmartScreen and "unknown publisher" friction for end users
• no first-class install/update/uninstall path
• no documented certificate/signing pipeline
• a weaker foundation for deeper Windows integration work around accessibility/UI automation and related platform APIs

Why this matters

Axidev OSK is already targeting Windows as a supported desktop platform. An official installer and code-signing story would make the project feel like a real Windows application instead of a loose archive download.

It should also improve the path toward Windows-specific accessibility and UI-facing APIs where proper packaging, signing, and trust matter in practice, while reducing SmartScreen friction for normal installs.

Scope

Define and implement the official Windows distribution approach, including installer format, signing approach, release automation, and user-facing install documentation.

This issue should cover the story at the product/release level, not just "generate a different artifact".

Packaging and runtime architecture context

Axidev OSK is currently shipped as a Python desktop application with a native input stack underneath it, not as a single self-contained native codebase.

Relevant packaging/runtime facts for this story:

• the top-level app package is axidev-osk, a Python package with the CLI entrypoint axidev-osk = axidev_osk.app:main
• the UI/runtime is primarily Python plus PySide6
• keyboard/input integration is not pure Python: the app depends on the vendored axidev-io-python package, which wraps native axidev-io C sources
• on Windows, that native layer uses normal Python extension tooling and Win32 libraries
• on Linux, the native layer depends on system libinput, libudev, and xkbcommon, and those are intentionally expected to remain dynamically linked from the host system
• Linux input features also depend on host permissions such as /dev/uinput access and relevant /dev/input/event* access
• current standalone release artifacts are built with scripts/build_standalone.py, which uses PyInstaller to bundle the Python runtime, the app package, and the Python/native dependency stack into a ZIP archive
• the current release flow publishes standalone ZIP artifacts for Windows and Linux, not a native installer/repository format for each platform yet
• licensing/compliance files for the vendored native stack are already carried into the standalone bundle and need to stay accounted for in any new packaging path

This issue should evaluate trade-offs against that runtime architecture explicitly so someone can reason about the packaging design without first reading the build scripts or code.## Acceptance criteria

• document the current packaging/runtime architecture, including Python runtime, native dependency stack, and artifact shape, so trade-offs can be reviewed without reading the code first
• choose and document the official Windows installer format and distribution approach
• choose and document the signing model for both the app binary and installer artifact
• integrate signing and installer production into the release pipeline
• publish a signed Windows installer as a release artifact
• document install, update, uninstall, and upgrade behavior
• document SmartScreen expectations and any remaining reputation caveats
• document how this packaging story affects or enables future accessibility/UI-automation/API integration work on Windows

Notes

Implementation could end up using MSI, MSIX, WiX, Inno Setup, NSIS, or another Windows-native path, but the issue should not assume the answer before the tradeoffs are evaluated.

[inayayousfi]

Follow-up: enforce Windows uiAccess-compatible build, signing, and install constraints

Problem

The current Windows standalone build does not explicitly enforce or verify the platform constraints required for uiAccess scenarios.

Even with an official installer, the resulting executable may still fail to meet Windows requirements if:

• the application manifest does not declare uiAccess="true",
• the executable is not Authenticode-signed,
• the installed location is not a protected path (e.g. Program Files),
• the signing and manifesting steps are not integrated into the build/release pipeline.

This makes it unclear whether the shipped Windows build is actually compatible with uiAccess expectations for accessibility and UI automation scenarios.

Goal

Ensure that the official Windows build and distribution pipeline produce an executable that satisfies the documented Windows requirements for uiAccess applications.

This issue is about enforcing build + signing + install invariants, not about choosing an installer format.

Scope

This issue covers:

• manifest configuration,
• code signing,
• installation path guarantees,
• CI/release pipeline integration,
• validation/verification steps.

It does not cover:

• implementing accessibility/UI automation features themselves,
• choosing between installer technologies beyond what is required to satisfy constraints.

Requirements

1. Application manifest (uiAccess)

The final Windows executable must include a manifest with:

<requestedExecutionLevel level="asInvoker" uiAccess="true" />

Requirements:

• the manifest must be embedded in the final built executable (not just present as a file),
• PyInstaller configuration must be updated accordingly (custom .manifest or .spec integration),
• verify that the manifest survives the full build process.

2. Authenticode signing

All relevant Windows artifacts must be signed:

• main executable (from PyInstaller),
• any helper executables if present,
• installer executable,
• uninstaller (if generated separately).

Requirements:

• use standard Authenticode signing (signtool or equivalent),
• include timestamping,
• signing must happen in CI (no manual local step),
• signing must occur after final binary generation.

3. Installation path constraints

The official install path must satisfy Windows protected location requirements:

• default install location:
  C:\Program Files\Axidev OSK\ (or equivalent)
• per-user install paths (e.g. %LOCALAPPDATA%) must not be the default for the official build,
• installer must not silently fall back to non-protected locations.

4. Build / release pipeline integration

The pipeline must:

1. build the standalone bundle (PyInstaller),
2. embed the correct manifest,
3. sign the produced binaries,
4. package the installer,
5. sign the installer,
6. publish the signed artifact.

Requirements:

• no step should require manual intervention,
• failures in signing or manifest injection must fail the build,
• pipeline must be reproducible.

5. Verification step (critical)

Add an explicit verification step in CI or release checks:

• verify signature:

  • signtool verify /pa <exe>

• verify manifest:

  • confirm uiAccess="true" is present in the embedded manifest

• verify install path (installer config):

  • check default target directory is under Program Files

This step must fail the build if any requirement is not met.

6. Documentation

Document:

• that the Windows build is intended to satisfy uiAccess deployment constraints,
• what those constraints are (manifest, signing, install location),
• that SmartScreen reputation is separate from uiAccess and may still show warnings initially,
• any limitations or caveats observed in practice.

Acceptance criteria

• final Windows executable contains embedded manifest with uiAccess="true"
• all shipped Windows binaries and installer artifacts are Authenticode-signed with timestamp
• official installer installs to Program Files by default
• signing and manifesting are fully integrated into CI/release pipeline
• automated verification step enforces all constraints
• documentation reflects actual behavior and limitations

[m13v]

hit this exact pattern working on desktop automation for windows. the moment you're asking for accessibility or input simulation access, users see 'unknown publisher' and trust goes zero. signed installer changes that from friction point to just another app. the UIA/accessibility story really does depend on it, not just distribution. SmartScreen isn't the blocker, it's the trust signal that lets users feel OK handing OS-level control to your tool.

[inayayousfi]

Yeah but I think I won't work on it for now until I get the keyboard in a really good state. But if you got any tips I would really appreciate it.