@wenathlan/saddle 1.8.11 → 1.8.13

package/docs/repo-synthesis-1.8.21.md

@@ -0,0 +1,112 @@
+# Comparative synthesis for Saddle 1.8.21
+
+The evidence set contains 60 public repositories selected across browser, scraping, storage, workflow, extension and packaging categories. Metadata, README excerpts, relevant tree paths and up to two code excerpts per repository were collected through the GitHub API. This document records patterns, not copied code.
+
+## Evidence coverage
+
+| Measure | Result |
+|---|---:|
+| Repositories analyzed | 60 |
+| Repositories with code samples | 35 |
+| Code samples captured | 64 |
+| Repositories with relevant paths | 54 |
+
+## Category coverage
+
+| Category | Repositories |
+|---|---:|
+| browser automation | 14 |
+| web scraping crawler | 11 |
+| s3 compatible storage | 11 |
+| browser extension automation | 10 |
+| package release artifacts | 7 |
+| workflow engine ci cd | 5 |
+| storage backup | 1 |
+| storage | 1 |
+
+## License and language signals
+
+The license field is evidence for comparison, not permission to copy. Any code reuse would require a separate compatibility review against GPL-3.0-only and the repository's complete notices.
+
+| License signal | Repositories |
+|---|---:|
+| unknown | 19 |
+| MIT | 16 |
+| Apache-2.0 | 13 |
+| AGPL-3.0 | 5 |
+| NOASSERTION | 3 |
+| GPL-2.0 | 1 |
+| WTFPL | 1 |
+| BSD-3-Clause | 1 |
+| BSD-2-Clause | 1 |
+
+| Language | Repositories |
+|---|---:|
+| Python | 15 |
+| TypeScript | 12 |
+| JavaScript | 8 |
+| Go | 8 |
+| unknown | 4 |
+| C++ | 3 |
+| Jupyter Notebook | 2 |
+| Rust | 1 |
+| Java | 1 |
+| PHP | 1 |
+| Zig | 1 |
+| Dockerfile | 1 |
+
+## Recurring implementation signals
+
+| Signal | Repositories with evidence |
+|---|---:|
+| queue | 22 |
+| storage | 43 |
+| browser | 33 |
+| workflow | 39 |
+| release | 49 |
+| security | 27 |
+
+## Most visible repositories in the evidence set
+
+| Repository | Stars | License | Categories |
+|---|---:|---|---|
+| [n8n-io/n8n](https://github.com/n8n-io/n8n) | 200533 | NOASSERTION | workflow engine ci cd |
+| [browser-use/browser-use](https://github.com/browser-use/browser-use) | 109121 | MIT | browser automation |
+| [puppeteer/puppeteer](https://github.com/puppeteer/puppeteer) | 95460 | Apache-2.0 | browser automation |
+| [microsoft/playwright](https://github.com/microsoft/playwright) | 94485 | Apache-2.0 | browser automation |
+| [scrapy/scrapy](https://github.com/scrapy/scrapy) | 63841 | BSD-3-Clause | web scraping crawler |
+| [minio/minio](https://github.com/minio/minio) | 61393 | AGPL-3.0 | s3 compatible storage |
+| [rclone/rclone](https://github.com/rclone/rclone) | 59129 | MIT | storage |
+| [apache/airflow](https://github.com/apache/airflow) | 46473 | Apache-2.0 | workflow engine ci cd |
+| [vercel-labs/agent-browser](https://github.com/vercel-labs/agent-browser) | 40571 | Apache-2.0 | browser automation |
+| [restic/restic](https://github.com/restic/restic) | 35497 | BSD-2-Clause | storage backup |
+| [SeleniumHQ/selenium](https://github.com/SeleniumHQ/selenium) | 34368 | Apache-2.0 | browser automation |
+| [apify/crawlee](https://github.com/apify/crawlee) | 25378 | Apache-2.0 | web scraping crawler |
+| [browserbase/stagehand](https://github.com/browserbase/stagehand) | 23931 | MIT | browser automation |
+| [prefecthq/prefect](https://github.com/prefecthq/prefect) | 23618 | Apache-2.0 | workflow engine ci cd |
+| [renovatebot/renovate](https://github.com/renovatebot/renovate) | 22257 | AGPL-3.0 | package release artifacts |
+
+## Objective-driven candidate gaps for 1.8.21
+
+The comparison suggests five independent feature directions. They are selected because they fit observed Saddle contracts and can be implemented without importing a provider's code or binding the library to hosted infrastructure.
+
+| Candidate | Comparable pattern | Saddle implementation boundary | Decision |
+|---|---|---|---|
+| Durable request leases | Crawlee and workflow engines make queue ownership, retries and persistence explicit. | Extend the existing persistent queue with caller-owned lease, visibility timeout, attempt count and idempotency key; keep storage adapters injectable. | Select for implementation |
+| Structured extraction contract | Stagehand and Crawlee separate observation/extraction from action execution. | Add schema-neutral extraction results with provenance, bounded payload size and injected parser; do not add an LLM or hosted browser dependency. | Select for implementation |
+| Browser context budget | Stagehand emphasizes token-efficient context and deterministic locators. | Add bounded snapshot projection with field allowlist, max bytes and stable element references, reusing existing snapshot/diff contracts. | Select for implementation |
+| Workflow cancellation and compensation | Temporal separates workflow state from worker execution and makes lifecycle state explicit. | Add an explicit cancellation transition and caller-owned compensation callback to the existing resumable run contract. | Select for implementation |
+| Artifact retention policy | Crawlee, release systems and storage projects separate durable results from transient worker state. | Add retention metadata and deterministic pruning decisions to artifact manifests without deleting caller data implicitly. | Select for implementation |
+
+## Rejected or deferred patterns
+
+Hosted stealth browsers, automatic proxy rotation, CAPTCHA solving, embedded object stores, cloud-specific dispatch APIs, native worker modules in the universal export graph and copying provider-specific code are rejected or deferred. They either violate caller-owned infrastructure, expand the security boundary, conflict with transport neutrality or require a separate legal and operational decision.
+
+## References
+
+[1]: https://github.com/browserbase/stagehand "Stagehand repository"
+[2]: https://github.com/apify/crawlee "Crawlee repository"
+[3]: https://github.com/temporalio/sdk-typescript "Temporal TypeScript SDK repository"
+[4]: https://github.com/minio/minio "MinIO repository"
+[5]: https://github.com/browser-use/browser-use "Browser Use repository"
+[6]: https://github.com/Scrapy/scrapy "Scrapy repository"

package/docs/s3compatible.md

@@ -0,0 +1,12 @@
+# S3-compatible storage listing
+
+The `s3compatible` adapter accepts a caller-owned signer and now implements the S3 ListObjectsV2 contract in addition to put, get, head and delete. `list(prefix, options)` sends the `list-type=2` query, preserves the caller's prefix, follows continuation tokens and stops at a bounded page count.
+
+```ts
+const objects = await storage.list("runs/", {
+  maxkeys: 1000,
+  maxpages: 20,
+});
+```
+
+Each returned object follows the storage adapter shape with `key`, `sizebytes`, `sha256` from the provider ETag when present, content type, creation time and provider metadata. XML entities are decoded before keys are returned. The adapter rejects a non-advancing continuation token and never creates credentials or chooses an endpoint on behalf of the caller.

package/docs/scanningresearch-1.8.11.md

@@ -0,0 +1,17 @@
+# Saddle 1.8.11 scanning research
+
+## OSV Scanner
+
+The official OSV Scanner GitHub Action documents separate pull request and full scheduled scans. The full reusable workflow can run on pushes, schedules and releases, upload SARIF to GitHub code scanning, and fail when a vulnerability is found. The action requires `actions: read`, `contents: read` and `security-events: write` permissions for SARIF reporting.
+
+Source: [OSV Scanner GitHub Action](https://google.github.io/osv-scanner/github-action/)
+
+## Cargo audit
+
+The official RustSec `cargo audit` documentation states that the tool audits dependencies for advisories in the RustSec database, operates on the top level Cargo project and requires Rust 1.74 or later. The Saddle workflow must run it against the resolved desktop `Cargo.lock`, keep any ignore entry narrowly justified, and prefer upgrading the vulnerable crate over suppressing the advisory.
+
+Source: [RustSec cargo audit README](https://github.com/rustsec/rustsec/blob/main/cargo-audit/README.md)
+
+## Pipeline decision
+
+Saddle should combine CodeQL for source and workflow analysis, OSV Scanner for multi ecosystem dependency intelligence and SARIF, `cargo audit` for RustSec coverage, npm audit for Node lockfiles, dependency review on pull requests, secret scanning, SBOM generation and artifact level checks. The pipeline should distinguish existing baseline findings from newly introduced findings, while release gates fail closed for high or critical reachable vulnerabilities and for the specifically reported glib advisory.

package/docs/securityreferences-1.8.11.md

@@ -0,0 +1,10 @@
+# Saddle 1.8.11 security references
+
+Android requires APKs to be digitally signed. Google Play separates the app signing key from the upload key and recommends keeping signing data out of Gradle files and public source. The Saddle workflow must use repository secrets or an external signing service, emit a test signed artifact only when explicitly labeled as such, and never commit a keystore.
+
+GitHub CodeQL supports JavaScript and TypeScript, Rust, Swift, Java and Kotlin, among other languages, as well as GitHub Actions workflows. Its findings can be displayed as code scanning alerts, and advanced setup can upload results to the repository. CodeQL complements, but does not replace, dependency advisory scanners such as `cargo audit`, npm audit and OSV based scanners.
+
+Sources:
+
+1. [Android app signing](https://developer.android.com/studio/publish/app-signing)
+2. [GitHub CodeQL code scanning](https://docs.github.com/en/code-security/concepts/code-scanning/codeql/codeql-code-scanning)

package/docs/securityresearch-1.8.11.md

@@ -0,0 +1,19 @@
+# Saddle 1.8.11 security research
+
+## Advisory scope
+
+The reported advisory is `GHSA-wrw7-89jp-8q8g`, also identified as `RUSTSEC-2024-0429`. It affects the Rust crate `glib` from version `0.15.0` through versions before `0.20.0`. The patched line is `glib >= 0.20.0`.
+
+The issue is an unsound `VariantStrIter` implementation. The affected iterator methods can reach a mutable C out-argument through an immutable Rust reference, which can lead to undefined behavior and null pointer dereference crashes in optimized builds. GitHub classifies the advisory as **Moderate**, with CVSS 4.0 base score `6.9`; no CVE identifier is assigned.
+
+The advisory is relevant to Saddle's native dependency graph because the desktop Tauri surface uses Rust and GTK/WebKit platform dependencies. The first remediation step is to inspect the resolved Cargo graph rather than assume that the direct application manifest is the only source of `glib`.
+
+## Required checks
+
+The security workflow must run `cargo tree` and `cargo audit` against the resolved desktop graph, report every `glib` version, and fail when an affected version is reachable in a release build. A direct dependency override must not be added blindly: GTK generation compatibility and the actual Tauri platform dependency graph must be checked before selecting an upgrade, patch release, or platform-specific mitigation.
+
+## Sources
+
+1. [GitHub Advisory Database: GHSA-wrw7-89jp-8q8g](https://github.com/advisories/GHSA-wrw7-89jp-8q8g)
+2. [RustSec: RUSTSEC-2024-0429](https://rustsec.org/advisories/RUSTSEC-2024-0429.html)
+3. [gtk-rs-core fix discussion](https://github.com/gtk-rs/gtk-rs-core/pull/1343)

package/docs/signingresearch-1.8.12.md

@@ -0,0 +1,167 @@
+# Binary signing research for Saddle 1.8.12
+
+## Scope and conclusion
+
+This investigation covered 30 search queries across official Microsoft, Apple, Android and GitHub documentation; open-source project workflows; signing-tool repositories; Stack Overflow, Security Stack Exchange, Reddit and public community discussions; and academic or standards sources on provenance and reproducible builds. The central conclusion is direct: **an open-source library can implement signing formats, but it cannot mint a certificate that Windows already trusts**. Public trust comes from a platform root program, a store, a certificate authority, a managed signing provider or an approved open-source signing program.
+
+The free options are therefore conditional rather than magical. Microsoft Store MSIX distribution can be re-signed by Microsoft. SignPath Foundation can sign eligible open-source projects. Google Play App Signing can protect the final Android key after the project creates an upload identity. Sigstore, Cosign, SLSA and in-toto can provide strong provenance and transparency, but they do not replace Authenticode for SmartScreen. macOS and iOS still require Apple program identities for public trust.
+
+## Research matrix
+
+|   # | Question investigated                                       | Evidence class                                     | Decision                                                                                                                         |
+| --: | ----------------------------------------------------------- | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+|   1 | How does Authenticode establish Windows publisher identity? | Microsoft documentation                            | It validates a certificate chain and signature; a free local key does not become a public identity.                              |
+|   2 | What signals does SmartScreen use?                          | Microsoft documentation                            | Publisher reputation and file-hash reputation both matter.                                                                       |
+|   3 | Does a new signed binary always avoid SmartScreen?          | Microsoft documentation                            | No. New signed files can still produce an initial warning while reputation accumulates.                                          |
+|   4 | Does EV still bypass SmartScreen?                           | Microsoft documentation                            | No. Microsoft states that EV no longer provides the former instant bypass.                                                       |
+|   5 | Does an unsigned binary inherit reputation?                 | Microsoft documentation                            | No. Unsigned versions begin with zero reputation for each new file.                                                              |
+|   6 | Does Microsoft Store distribution avoid the warning?        | Microsoft documentation                            | Store-distributed MSIX packages are re-signed by Microsoft and are the most reliable route.                                      |
+|   7 | Does the Store re-sign MSI and EXE installers?              | Microsoft documentation                            | No. MSI/EXE submissions still require a trusted Authenticode chain.                                                              |
+|   8 | Is Azure Artifact Signing free?                             | Microsoft documentation                            | It is a managed service with identity validation and a recurring cost; it is not an OSS certificate generator.                   |
+|   9 | Does SignPath Foundation offer OSS signing?                 | SignPath Foundation                                | Yes, for eligible projects; the service verifies repository-to-binary linkage and keeps keys in an HSM.                          |
+|  10 | Does SignPath issue a certificate locally?                  | SignPath Foundation                                | No. The provider controls the signing service and approval process.                                                              |
+|  11 | Can `osslsigncode` create public trust?                     | Open-source repository                             | It can implement Authenticode signing, but trust still depends on the certificate and chain supplied to it.                      |
+|  12 | Can Jsign create public trust?                              | Open-source repository                             | It can sign and timestamp PE, installer and script files; it does not create a trusted publisher identity.                       |
+|  13 | Can SignTool create a public certificate?                   | Microsoft tooling                                  | SignTool signs with an existing certificate and private key; it does not issue one.                                              |
+|  14 | Can Sigstore Cosign replace Authenticode?                   | Sigstore documentation                             | It provides keyless signatures and transparency for software artifacts, not a Windows Trusted Root certificate.                  |
+|  15 | Can Fulcio or Rekor make SmartScreen trust a PE file?       | Sigstore specifications                            | No evidence supports that substitution; use Sigstore as an integrity/provenance complement.                                      |
+|  16 | What does SLSA guarantee?                                   | SLSA specification                                 | It records how an artifact was built and can support verification; it does not establish Windows publisher reputation.           |
+|  17 | What does in-toto guarantee?                                | Academic and project sources                       | It protects supply-chain steps and provenance; it does not replace platform certificate trust.                                   |
+|  18 | Do reproducible builds remove SmartScreen warnings?         | Standards and Microsoft behavior                   | No. They improve independent verification, not Microsoft publisher or hash reputation.                                           |
+|  19 | Can timestamping make an unsigned artifact trusted?         | Authenticode tooling guidance                      | No. Timestamping preserves a valid signature after certificate expiry; it cannot create a signature.                             |
+|  20 | Does signing only the installer cover embedded executables? | Installer signing guidance                         | No general assumption is safe; embedded PE files should be signed and verified independently.                                    |
+|  21 | Can MSIX test certificates be used for public users?        | Microsoft MSIX guidance                            | No. Test certificates are for development or managed trust deployment.                                                           |
+|  22 | Can Google Play sign Android releases?                      | Android documentation                              | Yes, Play App Signing protects the final app-signing key after an upload key is configured.                                      |
+|  23 | Can Google Play sign direct APK downloads?                  | Android documentation                              | No. Direct APK distribution requires the project to sign the APK.                                                                |
+|  24 | Is Android upload-key generation free?                      | Android tooling                                    | Key generation is free, but the identity and distribution account are still project responsibilities.                            |
+|  25 | Can Apple Developer ID be generated by a library?           | Apple documentation                                | No. It is associated with an Apple Developer Program account and Account Holder privileges.                                      |
+|  26 | Can macOS notarization be performed without Developer ID?   | Apple documentation                                | No. Notarization is a service for Developer ID-signed software.                                                                  |
+|  27 | Can iOS provisioning be generated from source alone?        | Apple documentation                                | No. It is tied to an Apple team, certificates and profiles.                                                                      |
+|  28 | How does OpenCode sign Windows binaries?                    | Public OpenCode workflow                           | It uses Azure Artifact Signing with provider credentials and certificate profile data.                                           |
+|  29 | What does Zed demonstrate?                                  | Public Zed workflow                                | Release automation and package publishing can be open while provider and organization secrets remain private.                    |
+|  30 | What do community reports say about free certificates?      | Stack Overflow, Reddit and Security Stack Exchange | SignPath is repeatedly identified as the credible OSS route; anecdotal “certificate generators” do not establish platform trust. |
+
+## Open-source tools versus trusted identities
+
+The following tools are useful for Saddle, but none of them is a certificate authority:
+
+| Tool or project                | What it can do                                                                                                                                                                | What it cannot do                                                         |
+| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
+| `osslsigncode`                 | Authenticode sign, timestamp, verify, remove and extract signatures for PE, CAB, CAT, MSI, APPX and scripts                                                                   | Issue a Microsoft-trusted certificate                                     |
+| Jsign                          | Apache-licensed, cross-platform Authenticode signing, timestamping and verification for PE, MSI, MSIX, scripts and other formats; integrates with HSM and cloud key providers | Establish the publisher identity without a certificate or remote provider |
+| SignTool                       | Native Windows signing and verification                                                                                                                                       | Bypass certificate-chain or SmartScreen rules                             |
+| `rcodesign` / `apple-codesign` | Open implementation of Apple signing and notarization client workflows                                                                                                        | Create an Apple Developer ID identity                                     |
+| `apksigner`                    | Sign and verify Android APKs using a keystore                                                                                                                                 | Create a Google Play publisher account or replace Play App Signing        |
+| Cosign / Sigstore              | Keyless signatures, transparency and artifact verification                                                                                                                    | Make SmartScreen treat a PE file as Authenticode-signed                   |
+| SLSA / in-toto                 | Build provenance, attestations and supply-chain integrity                                                                                                                     | Become a platform trust root                                              |
+| Reproducible-build tooling     | Let independent parties rebuild and compare bytes                                                                                                                             | Remove first-download reputation warnings                                 |
+
+## Cost and trust classification
+
+| Route                        | Direct cost                                                                    | Identity requirement                   | SmartScreen/Gatekeeper result                                 |
+| ---------------------------- | ------------------------------------------------------------------------------ | -------------------------------------- | ------------------------------------------------------------- |
+| Self-signed test certificate | Free                                                                           | None beyond local key control          | Test or managed-enterprise trust only; public warnings remain |
+| No signature                 | Free                                                                           | None                                   | Strong warning and possible enterprise/SAC block              |
+| Microsoft Store MSIX         | Store and publisher onboarding costs may apply                                 | Store account and certification        | Microsoft re-signs the delivered MSIX                         |
+| SignPath Foundation          | Free for eligible OSS projects                                                 | Project review and provider acceptance | Provider signs the approved artifact                          |
+| Azure Artifact Signing       | Paid managed service; current Microsoft guidance lists approximately $10/month | Identity validation and cloud account  | Valid signing; reputation still builds over time              |
+| Traditional OV certificate   | Paid annual certificate                                                        | CA identity validation                 | Valid signing; new publisher/file reputation can still warn   |
+| EV certificate               | Paid and operationally heavier                                                 | Stronger CA validation                 | No longer a SmartScreen bypass by itself                      |
+| Apple Developer ID           | Paid Apple membership                                                          | Apple Developer Program team           | Developer ID signing plus notarization required               |
+| Google Play App Signing      | Play developer account and project onboarding                                  | Upload key and Play identity           | Google signs store-delivered APKs                             |
+| Sigstore                     | Often free for public CI identities                                            | OIDC identity and policy               | Verifiable provenance, not Authenticode trust                 |
+
+## Safe techniques that actually help
+
+The useful “tricks” are process improvements, not bypasses. Saddle should sign every nested PE file before signing the installer, use SHA-256 with a trusted timestamp service, preserve the exact bytes after signing, keep a stable publisher identity, publish checksums and SBOMs, attach GitHub artifact attestations, use protected release environments, restrict OIDC to tag-based jobs, and retain verification logs. A stable identity lets reputation accumulate; changing certificates or rebuilding different bytes for the same version works against that goal.
+
+The most reliable Windows user experience is Microsoft Store MSIX. The most realistic direct-download route for Saddle is to apply to SignPath Foundation or use Azure Artifact Signing. Until one of those approvals exists, the workflow should publish `unsigned` or `test` status and never claim that Windows will accept the binary without a warning. A generated local certificate may be useful for CI validation, but it must not be used as a public trust claim.
+
+The Sigstore Cosign quickstart confirms that keyless signing obtains a short-lived certificate from Fulcio after OIDC authentication, records the event in Rekor and verifies the bundle against the signing identity. This is valuable for a Saddle release manifest and supply-chain audit, but the Sigstore certificate is not an Authenticode certificate in the Microsoft Trusted Root Program. It should be attached as an integrity and provenance proof, not described as a SmartScreen bypass [7].
+
+The SLSA build-provenance specification describes the builder, external parameters, resolved dependencies and output subjects of a build. That lets an independent verifier establish where, when and how an artifact was produced, but it does not assert that Windows trusts the publisher or that SmartScreen will suppress a warning. Saddle should use SLSA-compatible provenance alongside, not instead of, platform signing [8].
+
+VSCodium is a particularly relevant open-source comparison. Its public distribution page says that the project builds and publishes its own Windows, macOS and Linux binaries, uses package-manager routes in addition to GitHub releases, and explicitly credits SignPath.io for free Windows code signing with a SignPath Foundation certificate. It also credits a separate macOS certificate contributor, showing that open-source projects commonly combine a community signing program for Windows with an independently held Apple identity rather than generating a universal certificate [23].
+
+The SignPath GitHub integration confirms the “hidden” mechanism that can look like a certificate generator from the outside: the workflow uploads the unsigned artifact, submits it with `SIGNPATH_API_TOKEN`, organization/project/policy identifiers and the GitHub artifact ID, then downloads the provider-signed output. SignPath checks that the build was performed by the expected GitHub workflow and that origin metadata came from GitHub rather than the build script. This is a legitimate managed-signing route, not a reusable certificate embedded in an open-source repository [24]. VSCodium's workflow directory also shows separate build and publish jobs for Linux, macOS and Windows, which supports the conclusion that the project uses explicit platform lanes rather than one cross-platform certificate [25].
+
+The additional provider search found OSSign, which advertises free code signing for qualifying open-source projects and requires an active project, a public automated build and public source review. Its page also states that applications were temporarily suspended because of a backlog. This is a promising second provider to evaluate, but it is still a managed service with eligibility and queue constraints, not a local certificate generator [26]. Let's Encrypt explicitly says that it issues free TLS certificates but does not issue certificates for code signing; using an ACME certificate for Authenticode would be a category error [27].
+
+Two additional IDE comparisons clarify the boundary. Lite XL documents newer Windows releases as self-signed and asks users to perform a first-run trust step; this is honest development or community distribution, but it does not remove public SmartScreen warnings. KeePassXC, in contrast, publicly raised funds to purchase a four-year Authenticode certificate for its Windows and macOS installers. The pair demonstrates that open-source projects either disclose a self-signed route or acquire/provider a real identity; neither approach generates a universally trusted certificate from source code [28] [29].
+
+Certum provides a less obvious but legitimate route: its Open Source Code Signing product is a paid certificate marketed to open-source developers, with the page displaying a current price and requiring a Certum cryptographic card and reader for activation. This is a conventional CA product with an open-source qualification, not a free generated key. Codegic is the opposite case: its own page says its free certificate is not from a publicly trusted CA and only removes the unknown-publisher warning after a root is manually trusted. It is suitable only for controlled environments and must not be presented as a public SmartScreen solution [30] [31].
+
+### Passive release-manifest reverse engineering
+
+The public release APIs were inspected without executing or installing any downloaded binary. VSCodium exposes separate Windows setup assets for `x64` and `arm64`, user and machine setup variants, each accompanied by hash files. Lite XL exposes Windows `i686` and `x86_64` archives/installers, macOS architecture-specific DMGs and Linux portable/AppImage outputs, while its documentation is explicit about self-signed Windows releases. KeePassXC publishes Windows MSI/ZIP, macOS DMG and Linux AppImage assets together with detached `.sig` and `.DIGEST` files. VimR's latest public release endpoint exposes a source archive rather than a universal signed app asset. These observations support a Saddle design with explicit per-platform lanes, architecture labels, detached integrity proofs and a separate platform-signing status rather than one generic “signed” flag [32] [33] [34] [35].
+
+The KeePassXC release checklist adds a useful workflow pattern: it builds Windows `amd64` and `arm64` separately with an explicit signing identity, builds macOS `x86_64` and `arm64` with `--sign --notarize`, checks the installed binaries, signs release files with GPG and uploads signatures/digests alongside the assets. Its checklist also includes a Microsoft Store update, showing that direct-download signing and Store distribution are separate release surfaces [36]. VimR documents the same distinction in a simpler form: a normal release is signed and notarized, while `notarize=false` intentionally produces an ad-hoc signature for local development. The project therefore demonstrates a safe status model rather than a hidden universal key [37].
+
+A passive byte inspection of a current KeePassXC MSI pair confirms that the `.DIGEST` asset is a textual SHA-256-style digest line, while the `.sig` asset begins with an ASCII-armored `PGP SIGNATURE` block. This is a reproducible pattern Saddle can adopt for detached integrity evidence, but it remains distinct from the embedded Windows Authenticode signature that controls publisher identity and SmartScreen behavior [34] [36].
+
+SignServer Community is a genuine open-source signing engine and can centralize signing keys, policies and audit trails. Its own repository states that the Community edition is intended for learning, testing and prototyping rather than production, while production deployments require the commercial edition or an equivalent operational model. SignServer therefore provides a possible self-hosted engine for Saddle's internal signing architecture, but it does not grant a Microsoft-trusted root or a free public certificate; the operator still needs a valid CA/provider identity and secure key custody [38] [39].
+
+The Eclipse Common Build Infrastructure documents a two-layer model that is useful for Saddle: projects sign all produced artifacts with a project-specific GPG web-of-trust key, and use platform code-signing certificates when deployment platforms can enforce them. Eclipse explicitly treats GPG as artifact integrity and platform signing as the mechanism that prevents platform warnings. The IntelliJ Platform comparison is different: it is an open-source foundation for building IDEs, but its source availability does not imply that every downstream IDE has the JetBrains publisher identity. In both cases, open source describes the code or build infrastructure, not a transferable signing identity [40] [41].
+
+## Route classification for Saddle
+
+| Classification               | Route                                                                                                                              | 1.8.12 decision                                                                                                                       |
+| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| Verified public route        | Microsoft Store MSIX/AppX                                                                                                          | Add as an optional distribution lane; Microsoft signs the Store-delivered package.                                                    |
+| Verified conditional route   | SignPath Foundation                                                                                                                | Apply with the public repository and reproducible GitHub workflow; integrate only after acceptance and policy identifiers are issued. |
+| Verified conditional route   | OSSign                                                                                                                             | Keep as a second application target; the current page reports a queue suspension, so it cannot be an immediate dependency.            |
+| Verified paid route          | Azure Artifact Signing or Certum Open Source                                                                                       | Use only after account validation, billing/renewal acceptance and protected secret setup.                                             |
+| Verified integrity route     | Cosign, GPG, detached digest, SLSA and in-toto                                                                                     | Add as release evidence; do not label it Authenticode or SmartScreen trust.                                                           |
+| Controlled-environment route | Codegic, self-signed certificate or SignServer CE                                                                                  | Allow only in explicit `test` or `enterprise-root` mode; never claim public Windows trust.                                            |
+| Unsupported route            | Let's Encrypt or an ordinary TLS ACME certificate                                                                                  | Reject because the issuer explicitly does not issue code-signing certificates.                                                        |
+| Unsafe route                 | Scraped certificate, copied publisher metadata, reused third-party signature, reputation farming or “certificate generator” bypass | Reject outright; these create impersonation, malware and revocation risks.                                                            |
+
+Academic measurements show why “a valid signature” is not the same as “safe software.” The USENIX study _The Broken Shield_ reports difficulties discovering abusive certificates, delays in revocation and failures in disseminating revocation information, which can leave clients trusting revoked certificates [21]. The arXiv study _Issued for Abuse_ documents underground trading of Authenticode certificates and connects that demand to attempts to bypass platform protections such as SmartScreen [22]. For Saddle, this means that a provider's identity review, HSM custody, protected release environment, provenance and revocation plan are security requirements, not optional decoration.
+
+## 1.8.12 implementation plan
+
+The next release should add an optional MSIX/AppX packaging lane, a SignPath or Azure provider adapter behind protected secrets, nested-PE signature verification, a signed-provenance bundle using Sigstore/SLSA-compatible metadata, and explicit release fields for `unsigned`, `caller-owned`, `provider-signed`, `store-signed` and `notarized`. The release must remain `1.8.12` only after the package manifests and release tag are intentionally bumped; the published `v1.8.11` tag must not be overwritten.
+
+## References
+
+[1]: https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/smartscreen-reputation "SmartScreen reputation for Windows app developers"
+[2]: https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/code-signing-options "Code signing options for Windows app developers"
+[3]: https://learn.microsoft.com/en-us/azure/artifact-signing/quickstart "Azure Artifact Signing quickstart"
+[4]: https://signpath.org/ "SignPath Foundation"
+[5]: https://github.com/mtrojnar/osslsigncode "osslsigncode"
+[6]: https://github.com/ebourg/jsign "Jsign"
+[7]: https://docs.sigstore.dev/quickstart/quickstart-cosign/ "Sigstore Cosign quickstart"
+[8]: https://slsa.dev/spec/v1.2/build-provenance "SLSA build provenance"
+[9]: https://in-toto.io/ "in-toto supply-chain integrity framework"
+[10]: https://developer.apple.com/developer-id/ "Apple Developer ID"
+[11]: https://developer.apple.com/programs/enroll/ "Apple Developer Program enrollment"
+[12]: https://developer.android.com/studio/publish/app-signing "Android app signing and Play App Signing"
+[13]: https://developer.android.com/tools/apksigner "Android apksigner"
+[14]: https://raw.githubusercontent.com/anomalyco/opencode/dev/.github/workflows/publish.yml "OpenCode publish workflow"
+[15]: https://raw.githubusercontent.com/zed-industries/zed/main/.github/workflows/after_release.yml "Zed post-release workflow"
+[16]: https://docs.github.com/en/actions/concepts/security/openid-connect "GitHub Actions OpenID Connect"
+[17]: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets "Using secrets in GitHub Actions"
+[18]: https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias "in-toto: Providing farm-to-table guarantees for bits and bytes"
+[19]: https://stackoverflow.com/questions/78848067/can-i-post-a-non-signed-msix-app-on-the-microsoft-store "Stack Overflow: unsigned MSIX and Microsoft Store"
+[20]: https://security.stackexchange.com/questions/139347/smart-screen-filter-still-complains-despite-i-signed-the-executable-why "Security Stack Exchange: SmartScreen after signing"
+[21]: https://www.usenix.org/conference/usenixsecurity18/presentation/kim "The Broken Shield: Measuring Revocation Effectiveness in the Windows Code-Signing PKI"
+[22]: https://arxiv.org/abs/1803.02931 "Issued for Abuse: Measuring the Underground Trade in Code Signing Certificate"
+[23]: https://vscodium.com/ "VSCodium open-source binary distribution"
+[24]: https://docs.signpath.io/trusted-build-systems/github "SignPath GitHub trusted build system"
+[25]: https://github.com/VSCodium/vscodium/tree/master/.github/workflows "VSCodium public workflows"
+[26]: https://ossign.org/ "OSSign code signing for open source"
+[27]: https://letsencrypt.org/docs/faq/ "Let's Encrypt FAQ"
+[28]: https://github.com/lite-xl/lite-xl "Lite XL source repository and release notes"
+[29]: https://keepassxc.org/blog/2017-03-04-authenticode-cert/ "KeePassXC funding an Authenticode certificate"
+[30]: https://certum.store/open-source-code-signing-code.html "Certum Open Source Code Signing certificate"
+[31]: https://www.codegic.com/code-signing-certificate/ "Codegic code signing certificate limits"
+[32]: https://github.com/VSCodium/vscodium/releases "VSCodium releases and architecture-specific assets"
+[33]: https://github.com/lite-xl/lite-xl/releases "Lite XL releases and package matrix"
+[34]: https://github.com/keepassxreboot/keepassxc/releases "KeePassXC releases with detached signatures and digests"
+[35]: https://github.com/qvacua/vimr/releases "VimR releases"
+[36]: https://github.com/keepassxreboot/keepassxc/wiki/Release-Checklist/ea3d900eedd4f765cf51763fc157ccee6b0118ab "KeePassXC release checklist"
+[37]: https://github.com/qvacua/vimr "VimR signed, notarized and ad-hoc build modes"
+[38]: https://www.signserver.org/ "SignServer Community open-source signing software"
+[39]: https://github.com/Keyfactor/signserver-ce "SignServer Community repository and production limits"
+[40]: https://eclipse.dev/cbi/best-practices/software-supply-chain/osssc-best-practices/ "Eclipse Open Source Software Supply Chain best practices"
+[41]: https://www.jetbrains.com/opensource/intellij-platform/ "IntelliJ Platform open-source foundation"

package/docs/signingwithoutcertificates.md

@@ -0,0 +1,54 @@
+# Signing Saddle without owning platform certificates
+
+Saddle cannot generate a certificate that Windows, Apple or an app store already trusts. A local self-signed certificate proves only that a test key signed the file; it does not establish publisher identity for public users. The reliable choices are a platform store, a managed signing provider, an open-source signing program or a certificate purchased and held by the project owner.
+
+## Decision matrix
+
+| Surface                | Route without an owned production certificate                                                                                                | What the project still needs                                                                                          | Result in the workflow                                                   |
+| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
+| Windows                | Submit an MSIX package to Microsoft Store, where Microsoft re-signs the package; apply to SignPath Foundation; or use Azure Artifact Signing | Store/SignPath/Azure acceptance and a release identity                                                                | Trusted only when the external provider or store has signed the artifact |
+| Windows direct EXE/MSI | SignPath Foundation or Azure Artifact Signing; traditional OV certificate is the paid fallback                                               | Provider account, repository binding and timestamp configuration                                                      | `caller-owned` signing status; unsigned output remains a test artifact   |
+| macOS                  | Mac App Store distribution or Apple Developer ID plus notarization                                                                           | Apple Developer Program membership, Account Holder access, certificate, hardened runtime and notarization credentials | `notarized` only after Apple accepts and staples the ticket              |
+| Android Play           | Google Play App Signing                                                                                                                      | Play Console account and a secret upload key; Google protects the final app-signing key                               | Google signs store APKs; direct APKs still require Saddle signing        |
+| Android direct APK     | Generate and protect a project keystore with `keytool`                                                                                       | Secret keystore, alias and separate passwords                                                                         | `caller-key` only after `apksigner verify` passes                        |
+| iOS App Store          | Apple signing and provisioning through the Apple Developer Program and App Store Connect                                                     | Apple team, distribution certificate, provisioning profile and export credentials                                     | IPA/app is distributable only after Apple signing succeeds               |
+| Browser extension      | No platform certificate is required for a local ZIP; store publishing uses the store account                                                 | Store publisher account and review                                                                                    | Package is identified by its manifest and release checksums              |
+
+Microsoft explicitly distinguishes free Microsoft Store MSIX re-signing from MSI/EXE submission, which still requires an Authenticode chain trusted by Microsoft. The same guidance lists self-signed and unsigned artifacts as development or testing options, not public-trust solutions [1]. SignPath Foundation is a legitimate open-source program that can provide a certificate for eligible projects and keeps the private key in an HSM; it is an application and approval process, not a package that manufactures trust locally [2].
+
+Apple requires a Developer ID certificate for Gatekeeper confidence outside the Mac App Store and recommends notarization after signing. The Developer ID certificate is created from an Apple Developer account by the Account Holder [3]. Android requires installable APKs to be signed; Play App Signing lets Google protect the final app-signing key while the project retains an upload key [4].
+
+## Recommended path for Saddle
+
+The first practical route is to apply to the [SignPath Foundation](https://signpath.org/apply) for Windows signing and simultaneously keep the current unsigned mode for artifacts produced before approval. If Microsoft Store distribution is acceptable, add an MSIX/AppX packaging target and submit that package instead of promising SmartScreen trust for the existing EXE/MSI files. OpenCode demonstrates the managed-provider route publicly: its release workflow uses Azure Artifact Signing with an endpoint, account name and certificate profile [5].
+
+For macOS and iOS, the project needs an Apple Developer Program team. No open-source framework can produce a universally trusted Developer ID certificate or Apple provisioning profile from source code. Android can use Google Play App Signing for Play distribution, but direct APK files still require a project-controlled upload/release key.
+
+## GitHub configuration steps
+
+The repository owner should acquire or be accepted by the appropriate provider first. The private files and passwords must never be pasted into chat, committed to the repository or printed by a workflow. In GitHub, open **Saddle → Settings → Secrets and variables → Actions → New repository secret** and add the values as repository or protected-environment secrets [6].
+
+The current workflow contracts are:
+
+| Provider               | Secrets                                                                                                                                             | Variables                                     |
+| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
+| Windows Authenticode   | `WINDOWS_CERTIFICATE_BASE64`, `WINDOWS_CERTIFICATE_PASSWORD`                                                                                        | `WINDOWS_TIMESTAMP_URL`                       |
+| Azure/SignPath adapter | Provider-specific endpoint, account/profile and OIDC or token values after approval                                                                 | Provider-specific non-secret identifiers      |
+| macOS desktop          | `APPLE_CERTIFICATE`, `APPLE_CERTIFICATE_PASSWORD`, `APPLE_SIGNING_IDENTITY`, `KEYCHAIN_PASSWORD`, `APPLE_ID`, `APPLE_APP_PASSWORD`, `APPLE_TEAM_ID` | None required by the current desktop contract |
+| Android                | `ANDROID_KEY_BASE64`, `ANDROID_KEY_ALIAS`, `ANDROID_STORE_PASSWORD`, `ANDROID_KEY_PASSWORD`                                                         | None required                                 |
+| iOS                    | `IOS_CERTIFICATE_BASE64`, `IOS_CERTIFICATE_PASSWORD`, `IOS_PROVISIONING_PROFILE_BASE64`, `KEYCHAIN_PASSWORD`                                        | `IOS_PROVISIONING_PROFILE_NAME`               |
+
+The workflow must run signing only for a trusted release event. Fork and Dependabot workflows do not receive normal repository secrets, so those jobs should build, scan and report unsigned/test status rather than attempting production signing [6]. The release manifest must state `unsigned`, `ci-test-key`, `caller-owned` or `notarized`; it must never equate a successful build with platform trust.
+
+## What not to do
+
+The project must not download a “universal certificate,” use a private key from another project, reuse a certificate from OpenCode or Zed, place a self-signed certificate in the public repository, or claim that SmartScreen, Gatekeeper or Play will trust an unsigned file. Those approaches either fail for users or create an impersonation and supply-chain risk.
+
+## References
+
+[1]: https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/code-signing-options "Microsoft code signing options for Windows app developers"
+[2]: https://signpath.org/ "SignPath Foundation"
+[3]: https://developer.apple.com/developer-id/ "Apple Developer ID signing and notarization"
+[4]: https://developer.android.com/studio/publish/app-signing "Android app signing and Play App Signing"
+[5]: https://raw.githubusercontent.com/anomalyco/opencode/dev/.github/workflows/publish.yml "OpenCode publish workflow"
+[6]: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets "Using secrets in GitHub Actions"

package/docs/signpathapplication.md

@@ -0,0 +1,11 @@
+# SignPath Foundation application
+
+The public application page is `https://signpath.org/apply`.
+
+The visible first section requests the project name, repository URL, homepage URL, download URL and privacy policy URL. SignPath states that the homepage should be a project website or repository page, while the download page must mention that the project uses SignPath Foundation for code signing. The application must be completed with public project information first; personal email and final submission remain caller-owned.
+
+The recommended Saddle integration is GitHub Actions because the repository has public release workflows and a reproducible build path. A generic CI/CD label is broader, while GitHub Actions identifies the trusted build system that SignPath can verify.
+
+The selected project license is GPL-3.0-only, an OSI-approved open-source license. The repository now keeps one canonical root `LICENSE` file with the official GPL v3.0 text and declares `GPL-3.0-only` in its package manifests. The public download page documents the requested SignPath Foundation code-signing policy while clearly marking approval as pending.
+
+The form is rendered by an embedded HubSpot flow. The page visually shows the public fields, but the browser automation layer does not expose those inputs as indexable controls, so direct coordinate entry is not reliable. The safe continuation is a user browser takeover on the already-open page. The agent must not enter the user's email or submit the application without an explicit final confirmation.

package/docs/sitemap.md

@@ -0,0 +1,14 @@
+# Sitemap traversal
+
+The sitemap parser follows nested sitemap indexes with a caller-defined maximum depth and URL count. It tracks visited sitemap documents to prevent cycles and canonicalizes URL identities without fragments so repeated references do not consume the result budget. `fetchSitemap` also accepts an injected fetcher for deterministic tests and caller-owned transport policy.
+
+```ts
+const urls = await parseSitemap("https://example.test/sitemap.xml", {
+  followIndexes: true,
+  maxDepth: 8,
+  maxUrls: 10000,
+  timeout: 10000,
+});
+```
+
+The parser does not select a proxy, browser, credential, host or port. Network failures continue to use the existing `WebScrapeError` contract, and the result remains a bounded array of normalized sitemap entries.

package/docs/tauri-glib-risk-1.8.11.md

@@ -0,0 +1,11 @@
+# Tauri and glib advisory decision
+
+The Tauri issue tracker confirms that Tauri's Linux surface can inherit the affected Rust GTK3/glib bindings transitively. The upstream discussion states that GTK3 bindings are archived and that the issue is blocked on upstream dependencies; a GTK4 migration remains an open feature request. Tauri maintainers also state that the affected iterator path is not used by Tauri itself, but this does not make the dependency advisory disappear from automated scanners.
+
+Saddle must therefore treat `GHSA-wrw7-89jp-8q8g` as a documented transitive limitation until the resolved desktop graph proves otherwise. The security workflow should fail on a newly introduced reachable affected version, but its baseline policy may allow this specific existing Linux-only advisory only through a reviewed, time-bounded ignore entry with the exact rationale and upstream tracking links. The release manifest must expose the accepted-risk status instead of labeling the Linux bundle fully clean.
+
+Sources:
+
+1. [Tauri issue #12048: glib-rs advisory](https://github.com/tauri-apps/tauri/issues/12048)
+2. [Tauri issue #7335: GTK4 migration](https://github.com/tauri-apps/tauri/issues/7335)
+3. [GHSA-wrw7-89jp-8q8g](https://github.com/advisories/GHSA-wrw7-89jp-8q8g)

package/docs/workflowinputs.md

@@ -0,0 +1,17 @@
+# Workflow input validation
+
+Workflow manifests can declare caller-owned input schemas. `validateworkflowinputs` rejects unknown fields, checks required values, applies defaults, converts string transport values to declared primitive types and enforces choices. `triggermatch` returns an `invalid-inputs` result instead of dispatching an invalid event.
+
+```ts
+const manifest = workflowmanifest({
+  name: "process",
+  command: "npm test",
+  inputs: {
+    count: { type: "number", required: true },
+    dryrun: { type: "boolean", default: false },
+    mode: { type: "string", choices: ["safe", "fast"] },
+  },
+});
+```
+
+When an event does not provide an explicit request ID, the trigger matcher derives one from the workflow name, trigger type and recursively sorted event data. The same logical event therefore receives the same identifier regardless of object key insertion order. No forge, host, port, credential or dispatch API is selected by this contract.

package/extension/manifest.json

@@ -1,10 +1,23 @@
 {
   "manifest_version": 3,
   "name": "Saddle browser bridge",
-  "version": "1.8.11",
+  "version": "1.8.13",
   "description": "User initiated page snapshots through the Saddle browser contract.",
   "minimum_chrome_version": "110",
   "permissions": ["activeTab", "scripting", "storage"],
+  "icons": {
+    "32": "icons/icon32.png",
+    "64": "icons/icon64.png",
+    "128": "icons/icon128.png"
+  },
   "background": { "service_worker": "worker.js", "type": "module" },
-  "action": { "default_title": "Saddle", "default_popup": "popup.html" }
+  "action": {
+    "default_title": "Saddle",
+    "default_popup": "popup.html",
+    "default_icon": {
+      "32": "icons/icon32.png",
+      "64": "icons/icon64.png",
+      "128": "icons/icon128.png"
+    }
+  }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wenathlan/saddle",
-  "version": "1.8.11",
+  "version": "1.8.13",
   "description": "binary computing engine that turns distributed storage into a publishable working set",
   "type": "module",
   "private": false,
@@ -74,6 +74,7 @@
     "./captcha-evidence": "./dist/captcha/evidence.js",
     "./hash": "./dist/core/hash.js",
     "./release-assets": "./dist/release/assets.js",
+    "./release-verify": "./dist/release/verify.js",
     "./worker": "./dist/runtime/worker.js"
   },
   "files": [