Skip to content

Releases: WasewaseX/Fress

Fress v1.0.4

Choose a tag to compare

@github-actions github-actions released this 18 Oct 14:35
ab2e272

Fress v1.0.4 — the quota-proof fallback release

The last path to "No download was started: the download sources could not be reached" is closed. v1.0.3 made the catalog's source lookups resilient (retries, quota conservation, stale-while-error); v1.0.4 adds the fallback for the one case that remained: a repository never looked up before, inside an exhausted rate-limit window. When the GitHub REST API still fails, the resolver now reads GitHub's own quota-free release documents instead of surfacing the error.

The fallback

  • The atom feed + asset fragments answer what the API answered. github.com/<repo>/releases.atom lists recent releases; the per-tag expanded_assets fragment carries one anchor per uploaded asset. Parsing is fail-closed: slug-validated URLs, a conservative tag charset, a bounded budget of fragment fetches per run, and entries that cannot be confidently attributed to the exact repository are skipped rather than guessed. The honest "no stable release" answer short-circuits the fallback; any other API failure earns one quota-free second opinion; if the fallback also fails, the original classified error is kept — the Retry button and failure kinds behave exactly as before.
  • A dedicated shape-validated request class. The review pass rejected the branch's original approach (widening the generic resolver-manifest allowlist with github.com) because a pinned audit invariant keeps github.com off the generic text policy — that invariant is what confines the self-update checksum document to its path-pinned policy. The shipped form admits github.com only for exactly the two release-document shapes, at admission and on every redirect hop; everything else on github.com fails closed.
  • Boundary-exact e2e deny-all carve-out (PR #111). The test harness's loopback exception matched hosts that merely start with localhost — localhost.evil.com would have slipped the net. Now the boundary is host-exact, pinned by unit tests.

Security posture

Unchanged and re-verified: URL admission, redirect rules, the public-address-only resolver, the minisign-verified self-update chain and the shape gate above are all enforced in the native layer; the audit's §10.14 round-6 documentation ships in this release (PR #109), and write_part_meta's contract doc now states the real fail-closed resume behavior (PR #112).

Quality

  • cargo test 275 passed / 0 failed · clippy -D warnings clean · fmt clean · 12/12 CI checks green
  • vitest 897 passed / 2 skipped (61 files) · tsc --noEmit clean · validate:versions 8 fields agree on 1.0.4

Full changelog: https://github.com/WasewaseX/Fress/blob/main/CHANGELOG.md

Fress v1.0.3

Choose a tag to compare

@github-actions github-actions released this 18 Oct 13:27
5d8630e

Fress v1.0.3 — the never-unreached release

This release closes, at the root, the error some users saw on the download button: "No download was started: the download sources could not be reached. Retry, or open the app for its official options."

What was wrong

Every catalog lookup (GitHub Releases, the F-Droid index, vendor manifests) was a single unauthenticated HTTP request. Three independent roots turned ordinary network weather into that failure:

  1. One dropped packet failed the whole lookup. A DNS hiccup, a connection reset, or a slow handshake — routine on throttled or censored networks — was never retried.
  2. The GitHub rate-limit window could be exhausted by browsing. Unauthenticated GitHub allows 60 requests/hour per IP, and every lookup spent 2–3 of them even when nothing had changed. Once drained, every lookup failed until the window reset.
  3. A failed lookup forgot everything the app already knew. Even a repository resolved successfully minutes earlier failed again from scratch.

What changed (native layer, api_resilience)

  • Transient failures are retried — up to four attempts with jittered exponential backoff; a server-sent Retry-After is honored (capped at 15 s). Deterministic answers (404, refusals, broken bodies) fail exactly once, as they should.
  • GitHub quota is conserved — every answer is cached with its ETag; repeat lookups revalidate with If-None-Match and a 304 costs no rate-limit budget. Steady-state browsing of an unchanged catalog spends almost no quota.
  • Stale-while-error — if every fresh attempt fails, the last known answer (up to 7 days old, refreshed by every successful revalidation) is served instead of an error: a slightly old release list still names real, downloadable files, and a working download beats an error toast.
  • Vendor manifests share the retry contract — a KDE mirror or Tor manifest behind one lost packet no longer fails the whole official-resolver chain.

Security posture

Unchanged. The resilience layer never constructs URLs, chooses hosts, or sees credentials; URL admission, redirect rules and the public-address-only resolver are exactly as audited. The cache stores only public API response bodies, atomically written, and can never become a new way for a lookup to fail.

Quality

  • 22 new tests over real loopback HTTP pin every serving path (fresh 200, quota-free 304 with on-the-wire If-None-Match proof, 5xx retries to success, exactly-once 404/403/redirect refusals, stale-serve through a rate-limited window, ancient-entry refusal).
  • cargo test 272 passed / 0 failed · clippy -D warnings clean · fmt clean · 12/12 CI checks green · validate:versions 8 fields agree on 1.0.3.

Full changelog: https://github.com/WasewaseX/Fress/blob/main/CHANGELOG.md

Fress v1.0.2

Choose a tag to compare

@github-actions github-actions released this 17 Oct 23:09
e60d2a9

Fress v1.0.2. A short directory of free and open-source apps.

Installers for every platform

Platform File
Windows (installer) Fress_*_x64-setup.exe
Windows (MSI) Fress_*_x64_en-US.msi
Windows (portable, no install) Fress_*_x64-portable.zip
Windows ARM64 (installer) Fress_*_arm64-setup.exe
Windows ARM64 (portable) Fress_*_arm64-portable.zip
macOS (Apple Silicon) Fress_*_aarch64.dmg
macOS (Intel) Fress_*_x64.dmg
Linux (AppImage) Fress_*_amd64.AppImage
Linux (deb) Fress_*_amd64.deb
Linux (rpm) Fress-*.x86_64.rpm
Android (universal APK, every device) Fress_*_universal.apk
Android (arm64 APK, smaller download) Fress_*_arm64.apk
Android (armv7 APK) Fress_*_arm.apk
Android (x86_64 / x86 APK) Fress_*_x64.apk / Fress_*_x86.apk

Where Fress is distributed
Only here, on the official GitHub Releases page of this repository, always with SHA256SUMS.txt next to the files. If you found a Fress installer on any other site or file host, it is not ours.

Windows: antivirus warnings and "Unknown Publisher"
The installer, the MSI and the portable exe carry the project's persistent publisher signature when CI has the certificate configured; until that signature chains to a trusted root, Microsoft Defender's machine-learning heuristics can still flag clean downloads (for example Trojan:Win32/Bearfoos.A!ml). Verify the SHA256 against SHA256SUMS.txt — if it matches, the file is exactly what this repository built. Reporting false positives, certificate setup and long-term signing plans: CODE_SIGNING.md in the repository. The blue "Unknown publisher" warning appears until a trusted certificate is in place: More info, then Run anyway.

macOS: first launch
The dmg is signed and notarized when the Apple credentials are configured in CI (see CODE_SIGNING.md). Without them, macOS may refuse to open the app the first time: right-click the app icon and choose Open, then confirm. That only happens once.

Verify any download against SHA256SUMS.txt.

Fress v1.0.1

Choose a tag to compare

@github-actions github-actions released this 17 Oct 11:12
7fcb4fe

1.0.1 (2026-10-17): the verified-boundary release

The first stable round's review findings are fixed, the download panel's Open / "Show in folder" actions work again on every desktop, and the whole open/reveal surface now crosses one registry-validated native boundary on every platform. TypeScript compiles under full strict mode and the strictness is enforced on every future change. Integration evidence: all five open audit/hardening pull requests (#92-#96) reviewed, defect-fixed and merged; the unit battery on the release tree is 860 passed / 2 environment-skipped across 57 files with tsc --noEmit clean under strict/noUnusedLocals/noImplicitReturns; the security validator, catalog validator, version-coherence validator and the no-Chinese source gate all pass on the release commit.

Open/reveal: the desktop actions work again, through one validated boundary

  • Open and "Show in folder" were silently refused on desktop in 1.0.0 - now fixed. The stable hardening removed the opener plugin's unrestricted open_path / reveal_item_in_dir webview grants (an any-file open/execute primitive), but the desktop buttons kept calling those plugin APIs - the capability layer refused every call at runtime, and the E2E suite could not see it because the test bridge answered requests the real binary denies. The frontend now binds the open/reveal policy to the registry-validated native commands on every platform: open_downloaded_file (the exact completion-event path, admitted by the session registry - canonical stability, regular file, committed size - then the OS is asked from the Rust side; on desktop via the opener plugin's Rust API, on Android via the fress-open installer/viewer adapter), reveal_download_file (the same registry discipline, desktop file-manager reveal), and open_download_dir for folder targets (the platform default download folder, a folder holding a completed artifact, or one the user picked this session via record_download_directory). A row restored after a restart keeps the affordance and gets the honest typed not-registered refusal - persisted webview-writable state still never feeds a native open. The E2E bridge now reproduces the capability denial, so reintroducing a plugin path call fails the suite loudly.
  • The delivered update artifact reveals through the same boundary (it is a completed engine download, admitted by the registry), and the update pill is pinned to the release it actually delivers - a pill for vNext can no longer reveal or re-offer the file a finished older delivery verified.

Native engine and boundaries

  • All-dots and Windows trailing-dot filenames can no longer break finalize. A server-supplied name like ... survived the sanitizer (only . and .. were caught) and reached CreateFile, which refuses or mangles dot-runs; trailing dots/spaces are dropped by Windows when it materializes a name, so a recorded path could disagree with the file on disk. The sanitizer now strips trailing dots/spaces and collapses every dot-run to the safe default, keeping the registry honest about what was written.

Native engine and boundaries

  • All-dots and Windows trailing-dot filenames can no longer break finalize. A server-supplied name like ... survived the sanitizer (only . and .. were caught) and reached CreateFile, which refuses or mangles dot-runs; trailing dots/spaces are dropped by Windows when it materializes a name, so a recorded path could disagree with the file on disk. The sanitizer now strips trailing dots/spaces and collapses every dot-run to the safe default, keeping the registry honest about what was written.
  • Opening and revealing downloads is a validated native boundary. The capability grants opener:allow-open-path / opener:allow-reveal-item-in-dir had no path scope — a compromised webview could open or execute ANY local file with the system handler. New native commands open_download_file / reveal_download_file admit only paths inside download-engine folders (the platform default download dir plus an app-owned, restart-proof ledger of folders a download actually ran in or the user picked via record_download_directory), and the two blanket grants are removed from the capability file. Residual risk is stated in the security docs.
  • F-Droid package ids are validated at the boundary. The id is interpolated into two pinned-host URLs; anything outside the store's own grammar (ASCII letters, digits, dots, underscores) is refused instead of being smuggled into a path.
  • The security validator tracks the real boundary. validate:security requires frontend evidence for all four native open/reveal commands and fails if either blanket opener path grant ever reappears in the capability file. The dependency audit of the shipped (production) tree reports zero known vulnerabilities; the two advisory hits in the development-only test runner (vitest's tinypool worker pool, prototype-pollution gadgets) never ship in the binary and are queued for the next tooling round.
  • A persisted resolver failure stays a failure. The persisted-cache read path cast a null hit through an as and could hand a failure entry to the digest revalidator; it now returns null (a known-failed lookup that Retry purges) instead of undefined ("nothing recorded").

Download manager

  • Cancelling one queued download can no longer evict its sibling. Cancel and promotion matched by URL; the same file legitimately queued for two folders made cancelling one row remove the other's queue entry too, leaving a permanently "queued" row with nothing behind it. Queue entries now carry the panel row's identity (localId) and match on it.
  • One failed start can no longer strand the whole queue. A rejected start inside the promotion pump escaped as an unhandled rejection and killed the loop, leaving every later queued entry stuck until an unrelated event happened to re-trigger promotion. The pump now survives the failure (the error toast is already up, the slot was never taken) and keeps draining the line.

Resolver cache

  • The Retry contract's eviction guard now matches its documentation. evictFailedLookups awaited a promise and then deleted by key alone — a fresh lookup stored under the same key while the await was in flight would be dropped instead of the stale failure. The guard now compares the exact promise it inspected.

Frontend

  • TypeScript compiles under strict, noUnusedLocals and noImplicitReturns. Fifty-four latent findings fixed, including a required githubUrl field that could actually receive undefined from the Add-App form, an unreachable-variable slug in the export preview, and dead imports/locals across the app. The type-level contract is now enforced on every future PR, not aspirational.
  • The palette's "alternative to" subtitle interpolates through a narrowed local; the compare modal's unrated-app cell renders the same blank it always did, with a real guard.

Update channels: the Stable channel serves stable releases only - a stable client is offered v1.0.1 and never a beta; beta-track clients (1.0.x-beta) are never silently downgraded. In-place update where the installer supports it; the Android track updates through the same signed, checksum-verified delivery.

Verification: every asset above is checksummed in SHA256SUMS.txt; the updater manifest (latest.json) carries the per-platform signatures the in-app updater verifies before any install. The release pipeline's final-artifact audit (tag-to-commit binding, manifest completeness, checksum agreement) ran on the published bytes and passed.

Integration: all five open review/hardening pull requests (#92-#96) were reviewed, defect-fixed and merged, plus three release-engineering fixes surfaced by the pipeline itself (#98, #99, #100). The full verification record lives in the CHANGELOG section above and in the merged audit documents.

Fress v1.0.0

Choose a tag to compare

@github-actions github-actions released this 14 Oct 16:40
78d5e8f

Fress v1.0.0. A short directory of free and open-source apps.

Installers for every platform

Platform File
Windows (installer) Fress_*_x64-setup.exe
Windows (MSI) Fress_*_x64_en-US.msi
Windows (portable, no install) Fress_*_x64-portable.zip
Windows ARM64 (installer) Fress_*_arm64-setup.exe
Windows ARM64 (portable) Fress_*_arm64-portable.zip
macOS (Apple Silicon) Fress_*_aarch64.dmg
macOS (Intel) Fress_*_x64.dmg
Linux (AppImage) Fress_*_amd64.AppImage
Linux (deb) Fress_*_amd64.deb
Linux (rpm) Fress-*.x86_64.rpm
Android (universal APK, every device) Fress_*_universal.apk
Android (arm64 APK, smaller download) Fress_*_arm64.apk
Android (armv7 APK) Fress_*_arm.apk
Android (x86_64 / x86 APK) Fress_*_x64.apk / Fress_*_x86.apk

Where Fress is distributed
Only here, on the official GitHub Releases page of this repository, always with SHA256SUMS.txt next to the files. If you found a Fress installer on any other site or file host, it is not ours.

Windows: antivirus warnings and "Unknown Publisher"
The installer, the MSI and the portable exe carry the project's persistent publisher signature when CI has the certificate configured; until that signature chains to a trusted root, Microsoft Defender's machine-learning heuristics can still flag clean downloads (for example Trojan:Win32/Bearfoos.A!ml). Verify the SHA256 against SHA256SUMS.txt — if it matches, the file is exactly what this repository built. Reporting false positives, certificate setup and long-term signing plans: CODE_SIGNING.md in the repository. The blue "Unknown publisher" warning appears until a trusted certificate is in place: More info, then Run anyway.

macOS: first launch
The dmg is signed and notarized when the Apple credentials are configured in CI (see CODE_SIGNING.md). Without them, macOS may refuse to open the app the first time: right-click the app icon and choose Open, then confirm. That only happens once.

Verify any download against SHA256SUMS.txt.

Fress v1.0.12-beta

Fress v1.0.12-beta Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 13 Oct 10:06

Fress v1.0.12-beta. A short directory of free and open-source apps.

Installers for every platform

Platform File
Windows (installer) Fress_*_x64-setup.exe
Windows (MSI) Fress_*_x64_en-US.msi
Windows (portable, no install) Fress_*_x64-portable.zip
Windows ARM64 (installer) Fress_*_arm64-setup.exe
Windows ARM64 (portable) Fress_*_arm64-portable.zip
macOS (Apple Silicon) Fress_*_aarch64.dmg
macOS (Intel) Fress_*_x64.dmg
Linux (AppImage) Fress_*_amd64.AppImage
Linux (deb) Fress_*_amd64.deb
Linux (rpm) Fress-*.x86_64.rpm
Android (universal APK, every device) Fress_*_universal.apk
Android (arm64 APK, smaller download) Fress_*_arm64.apk
Android (armv7 APK) Fress_*_arm.apk
Android (x86_64 / x86 APK) Fress_*_x64.apk / Fress_*_x86.apk

Where Fress is distributed
Only here, on the official GitHub Releases page of this repository, always with SHA256SUMS.txt next to the files. If you found a Fress installer on any other site or file host, it is not ours.

Windows: antivirus warnings and "Unknown Publisher"
The installer, the MSI and the portable exe carry the project's persistent publisher signature when CI has the certificate configured; until that signature chains to a trusted root, Microsoft Defender's machine-learning heuristics can still flag clean downloads (for example Trojan:Win32/Bearfoos.A!ml). Verify the SHA256 against SHA256SUMS.txt — if it matches, the file is exactly what this repository built. Reporting false positives, certificate setup and long-term signing plans: CODE_SIGNING.md in the repository. The blue "Unknown publisher" warning appears until a trusted certificate is in place: More info, then Run anyway.

macOS: first launch
The dmg is signed and notarized when the Apple credentials are configured in CI (see CODE_SIGNING.md). Without them, macOS may refuse to open the app the first time: right-click the app icon and choose Open, then confirm. That only happens once.

Verify any download against SHA256SUMS.txt.

Pre-release: features may change between releases.

Fress v1.0.11-beta

Fress v1.0.11-beta Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 13 Oct 00:08
6cc1d62

Fress v1.0.11-beta — the open-contract release

The download → open journey became real, then was proven as one integrated candidate: five parallel rounds (the desktop open contract, the end-to-end journey suite, executable version coherence, release-verifier hardening, user-facing docs truth) merged and re-verified together — full E2E suite 92/92, unit suite 605 passed, the new version validator green on this exact release candidate.

Downloaded apps actually open (desktop)

  • One uniform native boundary. Every completed artifact is handed to the OS opener with the exact completed path and the default handler — the OS association stays the authority, so Gatekeeper/UAC/package-manager checks stay in force. Open failures are typed and classified now (file gone, no handler, OS refused) instead of one generic message; the row stays completed and the action stays retryable without re-downloading.
  • Linux AppImages launch for real. Stock desktops ship no AppImage handler and downloads carry no execute bit, so the generic open always refused. The one fallback retries below the same boundary with a registry-validated launcher: it re-proves the artifact against the engine's own completion record (download id, exact committed path, canonical location and size — staging shapes, traversal targets and symlinks are refused by construction), sets the execute bit on that validated file only, and spawns it directly (argv, no shell, reaped in the background).
  • A launch in flight cannot be stacked. The open action announces its busy state (aria-busy) while staying interactive; a synchronous guard makes repeat activation a silent no-op — one click, one native launch.
  • Android's APK installer handoff (FileProvider content URIs to the system package installer) is scoped to the Android adapter's own round below the same boundary.

The journey is pinned end to end

  • Workflow K (22 browser tests) proves the complete download-to-open journey: exact per-row paths (two concurrent downloads can never cross-wire), keyboard-only activation landing exactly one launch per keypress, spaces/Unicode/shell-metacharacter filenames passing through as single values, honest Show-in-folder degradation with the containing-folder fallback, and the AppImage fallback receiving the same id and path the opener refused with — once, no retry loops.
  • The E2E bridge records every (boundary, id, path, with) tuple reaching the native layer, so opener-wiring regressions can no longer hide behind green state tests.

Release integrity became executable

  • One version-coherence command (npm run validate:versions) guards all six authoritative version surfaces — both lockfiles included — against one anchored grammar; both pipelines invoke it, and the release run binds the pushed tag to the build version.
  • The release artifact audit refuses bad input loudly: duplicate JSON keys in latest.json are a hard error, every advertised platform must match its asset's OS shape, malformed manifests fail with named reasons. Twenty new verifier tests pin the refusals; the VirusTotal skip is labeled informational, never silently green.
  • README and CODE_SIGNING were rewritten against the actual published release bytes: the per-artifact signing matrix, macOS Gatekeeper first-launch behavior, Android's same-key upgrade rule, and the honest Windows "Unknown publisher" explanation.

Install

Download the file for your platform below, verify it against SHA256SUMS.txt, and install it over your existing copy — same settings, same key. Windows (x64, ARM64), macOS (Intel, Apple Silicon), Linux (deb, rpm, AppImage) and Android (5 APK flavors) are all covered; the Windows installers and Linux bundles are signature-verified in-app before an update is ever called "verified".

Full details: CHANGELOG

Fress v1.0.10-beta

Fress v1.0.10-beta Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 12 Oct 20:09
a176e74

Fress v1.0.10-beta — the contrast-acceptance release

Four quality threads (native engine tests, updater delivery truth, audit honesty, i18n/a11y acceptance) merged, and the whole result was then re-verified as one integrated candidate by a fresh visual acceptance round: 46 harness tests and 67 screenshots of the real running app across both themes at every supported width. Every fix was reproduced on the rendered app before it was coded.

Every interface state is readable

  • The command palette's selected row reads in light mode. The selection highlight paints a solid cocoa band and the row's old inks sat on it at 1.06:1 (description), 1.12:1 ("vs proprietary" chip) and 2.53:1 (name). The selection surface now carries its own measured ink family, AA in both themes, pinned by automated contrast assertions.
  • App names never disappear from the palette. The "vs" chip could push the name to zero width on narrow windows and clip mid-word; the name keeps its space first now, the chip ellipsizes.
  • Dark-theme primary buttons hold WCAG AA. White labels on primary buttons, their hover states and the downloads count badge measured 4.02:1 / 2.71:1 on the default oklch sky steps — now 5.93:1 / 4.92:1, light theme unchanged.
  • The update pill tells the truth in every state: a refused in-app delivery says "see the releases page" in label AND tooltip; a cancelled transfer reconciles quietly instead of hanging the pill.
  • The export preview is keyboard-scrollable (a serious axe finding), and Privacy Pack controls are named by what they actually show — speech-input "click Gmail" matches now.

Engine and updater

  • The download registry records each artifact's checksum verdict and the signature verifier's diagnostics quote that provenance for the caller's own download; new tests pin cross-download record isolation and registry immutability after a failed verification.
  • The CI version guard also pins Cargo.lock; the scheduled live-network smoke test actually runs now.

Install

Download the file for your platform below, verify it against SHA256SUMS.txt, and install it over your existing copy — same settings, same key. Windows (x64, ARM64), macOS (Intel, Apple Silicon), Linux (deb, rpm, AppImage) and Android (5 APK flavors) are all covered; the Windows installers and Linux bundles are signature-verified in-app before an update is ever called "verified".

Full details: CHANGELOG

Fress v1.0.9-beta

Fress v1.0.9-beta Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 12 Oct 14:21
20c2259

Fress v1.0.9-beta. A short directory of free and open-source apps.

Installers for every platform

Platform File
Windows (installer) Fress_*_x64-setup.exe
Windows (MSI) Fress_*_x64_en-US.msi
Windows (portable, no install) Fress_*_x64-portable.zip
Windows ARM64 (installer) Fress_*_arm64-setup.exe
Windows ARM64 (portable) Fress_*_arm64-portable.zip
macOS (Apple Silicon) Fress_*_aarch64.dmg
macOS (Intel) Fress_*_x64.dmg
Linux (AppImage) Fress_*_amd64.AppImage
Linux (deb) Fress_*_amd64.deb
Linux (rpm) Fress-*.x86_64.rpm
Android (universal APK, every device) Fress_*_universal.apk
Android (arm64 APK, smaller download) Fress_*_arm64.apk
Android (armv7 APK) Fress_*_arm.apk
Android (x86_64 / x86 APK) Fress_*_x64.apk / Fress_*_x86.apk

Where Fress is distributed
Only here, on the official GitHub Releases page of this repository, always with SHA256SUMS.txt next to the files. If you found a Fress installer on any other site or file host, it is not ours.

Windows: antivirus warnings and "Unknown Publisher"
The installer, the MSI and the portable exe carry the project's persistent publisher signature when CI has the certificate configured; until that signature chains to a trusted root, Microsoft Defender's machine-learning heuristics can still flag clean downloads (for example Trojan:Win32/Bearfoos.A!ml). Verify the SHA256 against SHA256SUMS.txt — if it matches, the file is exactly what this repository built. Reporting false positives, certificate setup and long-term signing plans: CODE_SIGNING.md in the repository. The blue "Unknown publisher" warning appears until a trusted certificate is in place: More info, then Run anyway.

macOS: first launch
The dmg is signed and notarized when the Apple credentials are configured in CI (see CODE_SIGNING.md). Without them, macOS may refuse to open the app the first time: right-click the app icon and choose Open, then confirm. That only happens once.

Verify any download against SHA256SUMS.txt.

Pre-release: features may change between releases.

Fress v1.0.8-beta

Fress v1.0.8-beta Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 11 Oct 22:27
0585c13

Fress v1.0.8-beta — the integration release

Six parallel quality threads land together and are verified against each other: the updater's candidate selection becomes deterministic and architecture-safe, release artifacts gain a tested minisign verification path, the last data-driven English strings speak five languages, the catalog finishes its visual contract, and CI now runs the full browser suite on every change. One real user-facing bug this round fixed: an ARM-only release could be delivered to an Intel machine as a fully "verified" download — the delivery layer now refuses any release that ships no file the running machine can execute.

Self-update: deterministic selection, strict versions, artifact signatures

  • Versions parse strictly, anchored on both ends. The old pattern matched the 1.0.7 prefix of 1.0.7junk, so trailing junk rode into the candidate list as a stable release. Leading zeros, empty identifiers and unparsable tags are rejected now, and a malformed tag is eligible on no channel — it used to stay visible on every channel including Stable. Build metadata never affects precedence (SemVer rule 10).
  • Asset selection happens in two explicit phases. Hard platform/architecture/role gates decide what may be delivered at all; scoring only ranks the survivors. The old single-pass scoring kept ineligible assets alive at low scores, and because the scan started at −Infinity a lone ARM64-only dmg could win on an Intel Mac. Ranking is architecture-certainty first with a final lexicographic tie-break, so permuting the release's asset list can never change what you get.
  • The ARM-only worst case is closed. On an x64 host, an ARM64-only release used to resolve to an uninstallable file — and with a published checksum it arrived as a fully "verified" download. The hard gate refuses it; the header pill now routes to the Releases page instead.
  • Wrong-ABI Android files are refused, not merely ranked. armv7 apks on arm64 devices and x86 apks on x86_64 devices stay documented compatibility paths; everything else is a guaranteed install failure and can no longer win by being the only candidate.
  • Artifact authenticity: a native minisign verifier. verify_self_update_signature streams a completed download through minisign-verify (the Tauri updater's own crate family) against the public key embedded at compile time — the same key CI signs the Windows installers and Linux bundles with, byte-identical to the one published in tauri.conf.json. The v1.0.7 signatures were downloaded and verified against it row by row; the audit table lives in CODE_SIGNING.md. Legacy (non-prehashed) signatures are refused.

The last untranslated surfaces

  • Privacy Pack category names come from one shared mapping. All 28 category names resolve through one key map — card headings, ARIA labels, dropdown triggers, clear buttons and the picked-list label — so a second English display list can never grow back. A CI gate fails when a name lacks a mapping or a dictionary lacks the translation.
  • Download-option labels translate at render time. The data file keeps its English labels as identifiers, while the words you read follow the active language; product proper nouns stay and only the glue word translates ("Thunderbird für Windows", not "Thunderbird for Windows"). The translated label travels with the download record, so the download list names the entry exactly as the button you read.
  • The detail dialog's category badge, the export dialog and the last "Close dialog" ARIA labels speak five languages through the same shared mappings the cards and filters already use.

Visual contract, verified against the rendered app

  • Card and table category labels use the shared translation. A Persian or German UI no longer shows an uppercase English category string on every card.
  • Ghost text is readable. The table's zero-star placeholder and "Direct download" label sat at ~1.2:1 in light mode; the resolver-error note and the F-Droid CTA in the detail dialog carried near-invisible inks on their tinted wells. All ride proper per-theme text tokens now, pinned by contrast tests.
  • Long app names cannot break the card. The two-line clamp used to sit on the heading and was defeated by the inline button inside it — a 96-character stress name grew the card to four lines. The clamp lives on the button now, with the full name in a tooltip.
  • The theme menu closes when you pick a theme, and a full-disk download leaves a correct .part (the retained partial is flushed before the failure returns, so a resume can never start from a wrong offset).

Catalog resolver and native engine

  • New fixtures seed 35+ deterministic shuffles of a release carrying every decoy family the live audits found in the wild — source archives, wrong arch, wrong OS, help/lang packs, debug builds, CLI companions, server products — and assert the one correct installer wins in every order, on Windows and Android. The export dialog also stops swallowing clipboard failures: a refused copy now shows "Copy failed" with the button still usable.
  • 718 lines of adversarial test evidence for the download engine and network policy — production code untouched, verified hunk by hunk. The mock HTTP server learned If-Range, so conditional-resume behavior is exercised end to end.

CI runs the real app now

  • The full Playwright suite (ten user workflows plus 20 reviewed visual baselines) is a required CI job, running against the production build with a deny-all fixture network layer — shared GitHub quota can never flake a pull request. A weekly scheduled live-network smoke complements it without being a release gate.
  • Performance invariants are a required gate: zero unrelated card mutations during a 1000-event progress burst, persistence writes inside the coalescing bound. Wall-clock numbers are recorded as informational artifacts only.
  • The security-config validator is required, and the version guard pins both lockfile spots.

Upgrade

In-place update for every 1.0.x install — the updater offers 1.0.8-beta automatically (8 signed platform entries in latest.json, including windows-aarch64). Same Android signing key; no migration. If the release carries no file your machine can run, the updater links to the Releases page instead of offering a wrong file.