You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 45b0d53
Browse filesBrowse the repository at this point in the historyBrowse files
Version 1.0.1 in Cargo, Tauri, the UI package, the desktop entry, the
AppStream release list and the GitHub Action defaults; public trust now
covers 0.33.0-1.0.1 (same key and epoch) and the release docs name the
v1.0.1 tag rule. Changelog, release notes, README and the flagship ledger
describe the two window fixes: the window no longer grows on every
Wayland launch, and it fits small screens such as 1366x768.
The AppStream entry is dated 2026-10-01 (its expected UTC release day),
after 1.0.0, so the Debian changelog built from it stays in order.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Current release checkpoint (September 30, 2026): **1.0.0 is published and installed** ([run 36677001772](https://github.com/Shadowfetchapps/ShadowCode/actions/runs/36677001772), attempt 2: all 15 gates, signing and publication passed from `e0ab265`; installed here with the authenticated installer over 0.34.2, settings and history kept; see [the 1.0 program](#10-program)). Earlier pending statements below describe their historical checkpoints. Broader physical desktop, GPU endurance and live provider lifecycle acceptance remain open.
8
8
9
+
## 1.0.1 window fix
10
+
11
+
Checkpoint (September 30, 2026). Shadowfetch Linux 5.0 QA found two window defects in the installed 1.0.0 (KDE Plasma on Wayland, in a VM):
12
+
13
+
-**The window grew on every launch**, by about 52 px in width and 99 px in height (1380 px wide at the first launch, 1484 px at the third, then pinned to the top of the screen). On Wayland tao gives the window a GTK header bar (client-side decorations). `tauri-plugin-window-state` 2.4.1 saved the inner size from GTK's configure event, which includes the header bar and the shadow margins, and restoring it through `gtk_window_resize` added them again. The plugin now keeps every flag but `SIZE` (`window_size::REMEMBERED`): position, maximized, visibility, decorations and full screen are still restored. A size saved by 1.0.0 is ignored, so a window that already grew recovers at the next launch.
14
+
-**The default window (1380x920) was larger than a 1366x768 screen**, so the composer and status bar sat under the panel. The main window (`create: false`, built in code) now takes its first size from the screen it opens on: at most 90% of the screen, never more than its work area, less 48 px for the title bar (on Plasma the panel and the header bar are 46 px each). That gives 1229x643 on 1366x768 and leaves 1380x920 unchanged on 1920x1080. A screen that cannot hold the 520x640 minimum opens the window maximized. GTK on Wayland names no primary monitor (`gdk_display_get_primary_monitor` returned none on this host) and lets the compositor place the window, so there the smallest screen counts. The size is set before the window exists and the plugin restores a saved maximized state afterwards, so the fit never undoes it.
15
+
16
+
Verification before tagging 1.0.1: `cargo test --workspace --locked` (as the `native-source` gate runs it) 1469 passed / 0 failed / 14 ignored, including 10 new `window_size` tests; clippy clean except vendored glib; UI 715 unit and 111 Playwright tests; release, publisher, signing, release-auth, installer and packaging script suites 300 tests (299 passed; one packaging-environment test skipped: no cached linuxdeploy) plus `test-install-appimage.sh`; `appstreamcli validate --strict` passes, and the widened trust policy parses with the verifier's own parser (same key and epoch, range 0.33.0–1.0.1). The debug binary under Xvfb, with private home, XDG directories and D-Bus so the window-state plugin was active, opened at 1229x643 centered on a 1366x768 screen in three launches in a row, with the position kept and no size saved; on 1920x1080 it opened at 1380x920 although a saved 1.0.0 state said 1484x1019. Not checked here: a Wayland launch (this host has no Weston or WebKitWebDriver), so the growth fix itself is to be confirmed on KDE Plasma (Wayland) in the Shadowfetch Linux 5.0 VM with the packaged 1.0.1.
17
+
9
18
## 1.0 program
10
19
11
20
Checkpoint (September 29, 2026). The owner asked for 1.0.0: research the pain points people have with coding agents and fix them, "easy for anyone to use but advanced for real work". A survey of 32 pain points (8 already solved, 21 partly, 3 missing) set the scope. Work ran in two waves on `flagship/reliability-foundation`, each change with tests:
Copy file name to clipboardExpand all lines: docs/RELEASE_AUTHENTICATION.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Publisher authentication contract
2
2
3
-
The helpers in `scripts/native-release-auth.mjs` and `scripts/verify-native-release.sh` verify offline publisher signatures. They do not install, execute, download or publish an application, update trusted keys, or generate production keys. CI tests their behavior with disposable fixture keys. Public trust for 0.33.0–1.0.0 is tracked and the protected signing environment is configured. The installer uses these helpers before executing a candidate and explicitly refuses `--unverified`. [Version 0.33.1](https://github.com/Shadowfetchapps/ShadowCode/releases/tag/v0.33.1), published on September 28, 2026, is the first signed release.
3
+
The helpers in `scripts/native-release-auth.mjs` and `scripts/verify-native-release.sh` verify offline publisher signatures. They do not install, execute, download or publish an application, update trusted keys, or generate production keys. CI tests their behavior with disposable fixture keys. Public trust for 0.33.0–1.0.1 is tracked and the protected signing environment is configured. The installer uses these helpers before executing a candidate and explicitly refuses `--unverified`. [Version 0.33.1](https://github.com/Shadowfetchapps/ShadowCode/releases/tag/v0.33.1), published on September 28, 2026, is the first signed release.
4
4
5
5
The Bash verifier loads `scripts/native-release-auth-lib.sh` from its own script directory. Keep both reviewed code files together in the trusted tooling bundle; do not obtain the library from the candidate download or source metadata as shell code. The installer uses the same reviewed routines for current candidates and signed historical receipts; it never sources release metadata as code.
6
6
@@ -85,7 +85,7 @@ Each key has an inclusive version range and exactly one epoch. Unknown keys, dif
85
85
86
86
For a reviewed rotation, distribute a new authenticated trust bundle with the new public key and higher minimum epoch/version. Retain the old public key with its historical version range only when needed to verify an existing accepted-state receipt. The internal history check may ignore current minimum floors, but it still verifies the old signature, identity, key epoch and historical key range. This exception is not exposed as an install-verification API. Deleting an old key outright can make old state unverifiable; the installer must then fail pending explicit migration, not erase the state or assume a fresh install.
87
87
88
-
The tracked `release/trust` bundle contains the public Ed25519 key with ID `f0c60ff8228314616985712f8918c9798c0ecf72b7271e19343a041c25663b7f`. Its epoch is 1, minimum version is 0.33.0, and its inclusive key range is 0.33.0–1.0.0. It authorizes no later version without a reviewed policy update. The private key is not distributed in the repository or installer bundle. Fixture keys remain temporary and separate. Public fingerprint distribution, custody and future rotation/revocation remain owner responsibilities.
88
+
The tracked `release/trust` bundle contains the public Ed25519 key with ID `f0c60ff8228314616985712f8918c9798c0ecf72b7271e19343a041c25663b7f`. Its epoch is 1, minimum version is 0.33.0, and its inclusive key range is 0.33.0–1.0.1. It authorizes no later version without a reviewed policy update. The private key is not distributed in the repository or installer bundle. Fixture keys remain temporary and separate. Public fingerprint distribution, custody and future rotation/revocation remain owner responsibilities.
89
89
90
90
## Downgrade, replay and accepted state
91
91
@@ -132,8 +132,8 @@ A separate publisher runner receives the signing job's immutable artifact ID and
132
132
The workflow deliberately refuses missing owner configuration. The following records the 0.33.1 setup; recheck it before dispatching a release:
133
133
134
134
- The tracked `release/trust` public policy and key bundle must be included in the reviewed tooling commit and distributed through an authenticated channel. It contains public material only; no default fixture key is trusted.
135
-
- Repository variable `NATIVE_RELEASE_TOOLING_COMMIT` must pin the exact 40-character reviewed and pushed commit containing the current gate definitions, signing/publisher code, public trust and release-appropriate notes. The reviewed pin for 0.33.1 was `e15c4480e65db5650af012bb2a9773dbe89acf84`; for 1.0.0 it is the tagged `v1.0.0` release commit (`v0.34.2` for 0.34.2). Never infer this pin from an unreviewed tag.
136
-
- Repository variable `NATIVE_RELEASE_SIGNING_ENVIRONMENT` is set to `release-signing`. Its verified configuration requires the `Shadowfetchapps` User reviewer (ID `209457103`), allows self-review and retains GitHub's default administrator override. Its sole deployment rule allows the tag being released (`v1.0.0` for 1.0.0;`v0.34.2` and `v0.33.1` before). This is an owner-reviewed gate, not a two-person approval guarantee; a later release needs an explicit rule/policy update.
135
+
- Repository variable `NATIVE_RELEASE_TOOLING_COMMIT` must pin the exact 40-character reviewed and pushed commit containing the current gate definitions, signing/publisher code, public trust and release-appropriate notes. The reviewed pin for 0.33.1 was `e15c4480e65db5650af012bb2a9773dbe89acf84`; for 1.0.1 it is the tagged `v1.0.1` release commit (`v1.0.0` for 1.0.0, `v0.34.2` for 0.34.2). Never infer this pin from an unreviewed tag.
136
+
- Repository variable `NATIVE_RELEASE_SIGNING_ENVIRONMENT` is set to `release-signing`. Its verified configuration requires the `Shadowfetchapps` User reviewer (ID `209457103`), allows self-review and retains GitHub's default administrator override. Its sole deployment rule allows the tag being released (`v1.0.1` for 1.0.1; `v1.0.0`,`v0.34.2` and `v0.33.1` before). This is an owner-reviewed gate, not a two-person approval guarantee; a later release needs an explicit rule/policy update.
137
137
- Environment secret `NATIVE_RELEASE_SIGNING_KEY_PEM` has been uploaded to `release-signing`. It is scoped to the signing environment, not repository-wide secrets or the build job. Its presence does not prove that a candidate has been signed.
138
138
139
139
Owner review of the release workflow/source and repository protections remains necessary: another authorized workflow could request the same environment secret. Local gate receipts are validated assertions, not independent attestations that an adversarial producer executed the commands. Workflow dependencies and exact artifact IDs bind the proposed job flow; local fixtures do not prove GitHub control-plane behavior. Remote checks are observations, not atomic compare-and-swap against independently authorized concurrent changes.
0 commit comments