packaging: align remaining surfaces with v150.0.1 (deb/rpm/nix/Info.plist) + de-stale Linux source - #104
Merged
Merged
Conversation
…ath) Version-consistency pass over the non-manager packaging surfaces: - macOS Info.plist.template: CFBundle*Version 0.1.0-overlay -> 150.0.1 - nix flake: bearbrowserVersion -> 150.0.1 - deb/control: Version -> 150.0.1; replace stale 'Firefox ESR / 101-surface' copy with accurate Firefox-150 / BearNet / BearTrap description - rpm spec: Version -> 150.0.1 (+ changelog entry, history kept) - binary-source.env: retarget the 'single source of truth' away from the stale June 140.12.0esr GCS blob to the REAL v150.0.1 GitHub release tarball (verified structure: extracts to bearbrowser/, launcher bearbrowser/bearbrowser, sha256 52a0dcf1…). tor-mode Linux not built for 150 yet -> emptied (no stale sha). - RELEASE.md: add the v150.0.1 entry (history kept) Intentionally left at 0.1.0: RELEASE.md/rpm historical changelog entries, the homebrew Formula (CLI tooling, own overlay versioning), and the SELinux policy_module version (independent namespace).
mdheller
added a commit
that referenced
this pull request
Jul 30, 2026
…pstream product names Regression from PR #104 (my packaging cleanup a few days ago): I wrote 'LibreWolf-mirror fork of Firefox 150' in the deb description. verify-linux- packaging.sh forbids upstream product names ('LibreWolf|librewolf|Libre Wolf') to keep distribution branding coherent — a deb packager should read BearBrowser, not the base name. Turned the linux-packaging CI check red on main (and every PR since #104) — noticed only because #137 and #138 both have new YAML that queued a fresh CI run and I ran gh pr checks. Verified locally after fix: 'BearBrowser Linux packaging verified' Firefox is not banned (Mozilla's MPL requires attribution, and it's the engine name — plainly true and useful). Only the LibreWolf product name was the issue.
mdheller
added a commit
that referenced
this pull request
Jul 30, 2026
…ld (#138) * feat(rs-mirror): zero-trust review — we do not relay Mozilla blind Michael: 'zero trust dude we don't trust mozilla, we review the upstream and harden where possible too.' He is right and my earlier framing was still too trusting: a valid signature proves only that MOZILLA SIGNED IT, not that the content is benign. A compelled or compromised upstream ships signed records. review.mjs reads what we are about to serve and FAILS CLOSED on: a collection with no signature, a URL in signed content the collection has no business carrying, active-content markers (javascript:/<script/eval(), a new or vanished collection, or a >25% swing in record count — the shape a poisoned security list would take. A SHA256 baseline makes silent drift in already-vouched-for data visible on the next run. Made it collection-aware after the first pass produced noise — blunt rules get ignored, which is worse than no rule. ct-logs IS a list of log endpoints, intermediates embeds CPS URIs in certificate data, plugins/addons rows carry a user-facing 'why was this blocked' link. Those are inventoried; everywhere else a URL is a finding. (Same false-positive trap as calling plugins=5 a leak earlier — verify what upstream legitimately contains before alarming.) REAL findings from the first review of Mozilla PROD data: - Mozilla ships PLACEHOLDER urls in production CT data: https://ct.example.com/bogus/ and .../bogus/ipng/ - plugin-blocklist rows carry CLEARTEXT http:// advisory links (oracle, adobe, microsoft, divx, mozilla blog) Neither is fetched in normal operation, but we now SEE them instead of assuming, and the baseline diff surfaces the next change automatically. * fix(3 gaps): cockpit startup race + sovereign update channel + signing scaffold Closes the three items I flagged after v150.0.3. All three tested to the extent possible without a running build; each is behind an existing gate so a build without the corresponding piece is unaffected. 1. Cockpit startup race → cockpit-waiter.html. Was: new-tab opened resource://bearbrowser-cockpit/index.html immediately, but the gate at :8080 needed a beat to bind — cockpit UI hit ECONNREFUSED and looked broken. Now: new-tab points at a tiny waiter page in bearstart that polls http://127.0.0.1:8080/health with 250ms backoff and location.replace()s to the cockpit once the gate answers. 20s deadline with an honest 'the backend never bound' message if the cockpit was not assembled. Added to the packager stager and the verify-package.sh gate so a cockpit-carrying build without a waiter fails BEFORE ship. 2. Sovereign update channel → publish-latest-json.sh + weekly check in autoconfig + release-triggered workflow. Was: we killed aus5 correctly (leaks %OS_VERSION%/%BUILD_TARGET%/%LOCALE% per install) but that left NO channel to tell users a new version exists. Now: every release publishes a small latest.json to /releases/latest/ download/latest.json (idempotent). Autoconfig fetches it ONCE PER WEEK (pref-tracked timestamp), robustly parses semver-ish (rc suffixes → base version), and fires the observer 'bearbrowser-update-available' if newer. Header hygiene: credentials:'omit', referrerPolicy:'no-referrer', no cookies to GitHub. One request per user per week; no fingerprint-bearing template. Version parser tested inline: 5/5 cases pass. 3. Signing pipeline scaffolded (dispatch workflows, NO-OPS UNTIL SECRETS EXIST). Two new workflows: sign-and-notarize-macos.yml and sign-windows.yml. Both guard on their secrets and emit a ::warning:: without failing when Michael hasn't set them yet. When he does: macOS needs 6: APPLE_CODESIGN_IDENTITY, APPLE_ID, APPLE_APP_PASSWORD, APPLE_TEAM_ID, APPLE_P12_BASE64, APPLE_P12_PASSWORD Windows needs 2: WINDOWS_CODESIGN_PFX_BASE64, WINDOWS_CODESIGN_PFX_PASSWORD Both use ephemeral keychains/cert files that never persist on the runner. Both overwrite the ORIGINAL asset filename via --clobber so brew tap and winget URLs auto-pick up the signed version. macOS also regenerates SHA256SUMS.txt on the release so checksums stay honest. This is prep, not a signing event — it turns 'week of flailing' into ~10 minutes when the paid certs arrive. Not merging without Copilot review — draft. * fix: drop 'LibreWolf' from deb/control — linux-packaging check bans upstream product names Regression from PR #104 (my packaging cleanup a few days ago): I wrote 'LibreWolf-mirror fork of Firefox 150' in the deb description. verify-linux- packaging.sh forbids upstream product names ('LibreWolf|librewolf|Libre Wolf') to keep distribution branding coherent — a deb packager should read BearBrowser, not the base name. Turned the linux-packaging CI check red on main (and every PR since #104) — noticed only because #137 and #138 both have new YAML that queued a fresh CI run and I ran gh pr checks. Verified locally after fix: 'BearBrowser Linux packaging verified' Firefox is not banned (Mozilla's MPL requires attribution, and it's the engine name — plainly true and useful). Only the LibreWolf product name was the issue.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Finishes the version-consistency sweep the manager manifests (brew/choco/winget) started.
Bumped to 150.0.1: macOS
Info.plist.template,nix/flake.nix,deb/control,rpm/bearbrowser.spec.De-staled (not just a number):
deb/controldescription said "Firefox ESR … 101-surface fingerprinting shield" → now accurate (Firefox 150 fork, BearNet, BearTrap).binary-source.env(the self-described single source of truth) pointed at a stale June140.12.0esrbinary in a private GCS bucket. Retargeted at the real v150.0.1 GitHub release tarball — verified structure (extracts tobearbrowser/, launcherbearbrowser/bearbrowser, sha25652a0dcf1…). tor-mode Linux isn't built for 150 yet, so its fields are emptied rather than carrying a stale checksum.Left at 0.1.0 on purpose: historical changelog entries (RELEASE.md, rpm), the Homebrew Formula (CLI tooling with its own overlay versioning), and the SELinux
policy_moduleversion (independent namespace).No functional/build change — metadata + source-pointer correctness.