Repository navigation
chore(python): document Smart App Control workaround and reproduction - #2793
Merged
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
bashkit | d014192 | Commit Preview URL Branch Preview URL |
Oct 28 2026, 12:12 AM |
7 of 8 tasks
chaliy
added a commit
that referenced
this pull request
Oct 30, 2026
## What changed Windows Python releases now require timestamped Authenticode signatures on native files before the wheel can enter the PyPI upload set. A shared Azure OIDC signer runs on a separate Windows runner, rejects refs outside immutable main-reachable release/test tags, repacks with fresh RECORD hashes, and verifies the signatures extracted from the final archive. Build and smoke jobs never receive the signing identity. A manual signing-only workflow uses the same production signer on a hash-checked copy of the published 0.20.1 Windows wheel. It installs the resulting validation wheel on a separate Windows runner and tests native import during pytest plugin loading plus sandbox execution. It publishes no registry package or GitHub release. Public Azure identifiers are configuration; no private key or client secret is stored in GitHub. ## Why PondGuard reported SAC blocking Bashkit 0.20.1's native module while 0.20.0 loaded. Both published Windows modules lack embedded signatures. This implements the signing path following #2793 while retaining the reported pin until a new signed production release passes the SAC-On check. ## Before / After Before: the unsigned Windows build artifact matched the PyPI upload glob directly. After: it remains under pypi_unsigned-*; only the successfully signed, verified, repacked wheel becomes pypi_files-windows-*. Any signing, timestamp, RECORD, or native-integrity failure blocks publication. Validation: 204 local script tests run (4 skipped); Windows native signature/packaging tests and both hash-pinned published-wheel import/execution baselines passed on earlier revisions. Latest CI is running. Real Git fixtures reject branch refs and tags outside main. Source/documentation checks pass, including parity of all 396 threat IDs. Local Rust/just checks are unavailable; full repository CI covers the change. Production signing will be exercised after merge from its protected main-reachable test tag; the signing-only workflow cannot publish. The new threat entry initially failed the public-doc parity test; the public copy is now synchronized. No actual SAC enforcement result is claimed. ## Risk - Medium: missing or invalid signing prerequisites intentionally block PyPI publication. - Azure Individual publisher verification, Active bashkit-public Public Trust profile, v*-tag-only GitHub environment, and profile-scoped OIDC signer permission are configured. - Hosted Windows Server checks do not establish Windows 11 SAC enforcement. Validate the final signed artifact there before claiming compatibility. ## Checklist - [x] Tests for wheel hash repair, metadata tampering, artifact routing, credential isolation, real Windows signatures, and immutable source/tag checks - [x] Backward compatibility considered; Python runtime API unchanged - [x] Publisher identity validated; bashkit-public Public Trust profile Active - [x] release-windows-signing environment accepts only v* tags - [x] Certificate Profile Signer scoped to that single profile - [ ] Latest CI green - [ ] Post-merge production signing-only workflow passes Azure OIDC, signing, timestamp and pytest checks - [ ] SAC-On native import/execution and affected project pytest collection validated before declaring a production signed release fixed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Document the reported Windows workaround for Bashkit 0.20.1: retain Smart App Control, pin Bashkit 0.20.0 in the affected application's environment and dependency resolution, then verify import, execution, and pytest. Add an A/B PowerShell procedure that preserves install reports, native hashes, Authenticode status, and Code Integrity event XML. Link it from the Python package README.
Why
PondGuard reported a 0.20.1 native-module block on Windows 11 / Python 3.11.9. Users need a workaround and evidence collection steps before attributing the failure to signing or provenance.
Before / After
Documentation only; runtime behavior is unchanged. Previously the Python guide offered no SAC recovery or reproduction steps. It now distinguishes launcher blocks, native-module blocks, and transitive pytest plugin imports, with a temporary constraint and a trusted-signing release plan.
Artifact inspection downloaded both published cp39-abi3-win_amd64 wheels and verified their SHA-256 against PyPI JSON. Both modules have empty PE certificate tables, both wheels use maturin 1.15.0, both PyPI wheel provenance endpoints returned HTTP 404, and the release-tag Python publish workflows are identical. The guide records exact wheel/native hashes. This does not establish the Windows policy decision or binary reputation.
Validation: all 185 scripts/tests tests passed (2 skipped); documentation links, OKF, workflow parity, changelog, capability parity, and git diff checks passed. Local just pre-pr could not run because this environment lacks just and the Rust toolchain. No native code or workflow changed. Windows/SAC execution and the PowerShell procedure are unverified here because the available environment is Linux. No authenticated X coverage was used.
Risk
Checklist