docs(readme): distinguish signed release binaries from unsigned source builds in SmartScreen section#14
Conversation
…e builds in SmartScreen section Per highperformance-tech#8, the README claimed the Windows binary was unsigned, but release.yml runs a sign-windows job that Authenticode-signs the amd64/arm64 executables via Azure Trusted Signing before packaging them. Only source builds remain unsigned. Reworded the section to: - note release binaries are signed and shouldn't trigger SmartScreen - keep the Unblock-File guidance, scoped to source builds Closes highperformance-tech#8
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
Superseded by #15, which rolls this README change in alongside the connector dialect-subcommand refactor and other Phase 3 scope. |
2 participants
Summary
Per #8, the README's Windows SmartScreen section told users the Windows binary was unsigned and would trigger SmartScreen. Meanwhile, `.github/workflows/release.yml` runs a `sign-windows` job that Authenticode-signs both amd64 and arm64 Windows executables via Azure Trusted Signing before packaging — so GitHub Release downloads should not prompt.
Reworded the section to keep the accurate info (source builds remain unsigned, Unblock-File guidance still helpful for those cases) while correcting the claim for release binaries.
Closes #8
Testing
Docs-only change.