# InterGenOS R001.4 — Release Notes **Released:** 2026-10-25 **Designation:** R001.4 — the fourth point release of the InterGenOS release line, a fix-only point release issued ahead of R002. --- ## Why this release exists **Critical: the system certificate bundle.** Eight eMudhra intermediate certificate-authority keys were compromised: six TLS-issuing and two code-signing intermediates under emSign Root TLS CA - G3 and emSign Root CS CA - G3, cross-signed by Sectigo AAA. Mozilla's OneCRL and Chrome's CRLSet blocked them on 17 October 2026; NSS 3.131.1 removed the root on 20 October. **R001.3 is affected.** An attacker holding those keys can present a certificate for a site that an R001.3 machine accepts as genuine: the connection looks secure and is not. R001.3's bundle (ca-certificates 2026.04.30, 121 certificates) still trusts emSign ECC Root CA - G3, and we confirmed the exposure on an R001.3 machine: a certificate chained to the compromised keys passed TLS verification against a public test host. Until a machine is updated, every TLS connection it makes trusts that root. **The fix.** R001.4 moves the system bundle to Mozilla's snapshot dated 20 October 2026 (ca-certificates 2026.10.20, 118 roots), which drops that root along with the snapshot's other removals. The roots removed and added are listed in the `[R001.4]` section of `CHANGELOG.md`. R001.4 is a fix-only point release under the bounded exception in `docs/release-policy.md` in the source repository: R001.3 reached the policy's drift limit and the complete from-source rebuild remains the next major release, R002; a point release past that limit carries only urgent security, assistant transparency and accuracy, update-path and hardware fixes, and discloses every package it changes — the full list is under *Every package changed in R001.4* below. Every changed package was recompiled against R001's substrate with the full validation gate set enforced; the image was then installed and evaluated on real hardware and in a virtual machine before publication. --- ## If you run R001.3 Update now: ```sh sudo pkm upgrade --all ``` This moves an installed R001.3 system onto R001.4's package set from the signed mirror, the certificate bundle included. You do not need this image; it exists for new installations and for verifying what the release contains. Two messages can appear during the upgrade, and neither needs a rollback; both are explained under *Upgrading from R001.3: two known issues* below. --- ## Download | | | |---|---| | **Image** | [`intergenos-r001.4.iso`](https://repo.intergenos.org/iso/intergenos-r001.4.iso) | | **Size** | 10,489,925,632 bytes (9.77 GiB) | | **SHA-256** | `4608b40b9d8854a36489a435776e9bb08e20c7dd03cadf02929632b2cfe5b7d0` | | **Checksum file** | [`intergenos-r001.4.iso.sha256`](https://repo.intergenos.org/iso/intergenos-r001.4.iso.sha256) — signed, see [`.sha256.asc`](https://repo.intergenos.org/iso/intergenos-r001.4.iso.sha256.asc) | | **Architecture** | x86_64 | | **Boot mode** | UEFI only — there is no legacy BIOS fallback | | **Image type** | Live ISO with a graphical installer | The package mirror for this release is `https://repo.intergenos.org/x86_64/current/`. Its index is signed; see *Verifying this release* below. --- ## Verifying this release Four things can be verified independently, and none of them requires trusting this document. Do them in this order: the key first, then everything the key attests. ### 1. Get the release public key R001.4 is signed by the same key as R001, R001.1, R001.2 and R001.3. The key is served from three places, and fetching from more than one and comparing the fingerprint is stronger than fetching from any single one: ```sh # From the project mirror curl -O https://repo.intergenos.org/keys/intergenos-release-key.asc gpg --import intergenos-release-key.asc # Or from keys.openpgp.org gpg --keyserver keys.openpgp.org \ --recv-keys 5597A3E0587B253006D0DD7B8C50826182083050 # Or from keyserver.ubuntu.com gpg --keyserver keyserver.ubuntu.com \ --recv-keys 5597A3E0587B253006D0DD7B8C50826182083050 ``` **The fingerprint to check is the primary key's:** ``` 5597 A3E0 587B 2530 06D0 DD7B 8C50 8261 8208 3050 ``` That primary key carries several signing subkeys. The subkey that signed this release's image checksum, package index and source tag is: ``` D7AA 641D 81AC D690 C5AD 865E 7276 E14D D888 6BFE ``` Both fingerprints are correct, and they are not interchangeable. Certify and compare the **primary** fingerprint — a subkey fingerprint is what your tools report as "using RSA key …" when they check a signature, and it changes when a subkey is rotated. Confirm what you imported with: ```sh gpg --list-keys --with-subkey-fingerprint 5597A3E0587B253006D0DD7B8C50826182083050 ``` ### 2. Verify the ISO checksum The checksum file is signed, so check the signature before you trust the checksum. Verify in that order — signature first, then the image against the checksum it attests: ```sh curl -O https://repo.intergenos.org/iso/intergenos-r001.4.iso curl -O https://repo.intergenos.org/iso/intergenos-r001.4.iso.sha256 curl -O https://repo.intergenos.org/iso/intergenos-r001.4.iso.sha256.asc # 2a. Is the checksum file the project's? gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg gpgv --keyring ./release-key.gpg \ intergenos-r001.4.iso.sha256.asc intergenos-r001.4.iso.sha256 # 2b. Is the image the one that checksum names? sha256sum -c intergenos-r001.4.iso.sha256 ``` Expect `Good signature from "InterGenOS Project Signing Key (primary)"` from the first command, and `intergenos-r001.4.iso: OK` from the second. Doing both halves matters, and each answers a different question. The signature proves the checksum file is the project's and has not been altered in transit or on the mirror. It does not, by itself, say anything about the file sitting on your disk — hashing the image against that checksum is your step, and it is the one that catches a truncated download or a substituted image. If you write the image to a USB stick, verify the stick after writing rather than trusting that the write command exited successfully: read back exactly the image's byte count from the device and hash that. ### 3. Verify the signed package index The mirror's package index is a signed manifest of the whole repository. The signature covers the entire index, so one verification covers every package listed in it: ```sh curl -O https://repo.intergenos.org/x86_64/current/InterGenOS.db curl -O https://repo.intergenos.org/x86_64/current/InterGenOS.db.sig gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg gpgv --keyring ./release-key.gpg InterGenOS.db.sig InterGenOS.db ``` Expect `Good signature`. Use `gpgv` rather than `gpg --verify` here: `gpgv` checks the signature against exactly the keyring you name and nothing else, which is what you want when the question is "was this file signed by that key." The index is gzip-compressed JSON. Every package entry in it carries a `sha256` of that package's archive, so the one index signature transitively attests every published package's bytes. An entry whose package declares an upstream source also carries `source_sha256`, the digest of the corresponding source archive published beside the binaries (1,104 of the 1,146 entries; the other 42 declare no upstream source). ### 4. Verify the signed release tag The source tree for this release is tagged `R001.4`, and the tag is signed: ```sh git clone https://github.com/InterGenJLU/intergenos.git cd intergenos git tag -v R001.4 ``` Expect `Good signature from "InterGenOS Project Signing Key (primary)"`. Git reports the signing subkey `D7AA641D…`; the primary key it belongs to is `5597A3E0…`, which is the one you compared in step 1. Until GnuPG is told you trust this key, it also prints: ``` WARNING: This key is not certified with a trusted signature! ``` That warning is about *your* trust decision, not about the signature. It means the signature is cryptographically good and you have not yet certified that the key belongs to whom you believe it does. Comparing the primary fingerprint against more than one independent source, as in step 1, is how you settle that. --- ## What is in this release Measured from the source tree this release was built from and from the signed mirror index generated 2026-10-25T05:11:27Z: | | Count | |---|---| | Package definitions in the source tree | 1,194 | | Packages that ship on the installation image | 873 | | Package definitions that resolve to mirror-only | 321 | | — of those, published in the signed mirror index | 292 | | — of those, build-stage intermediates that are never published | 29 | | Packages published in the signed mirror index | 1,146 | These figures count different things, so they do not subtract into each other. Counted as sets: 873 shipping packages + 321 mirror-only definitions = 1,194, every definition counted once under its own name. The 1,146 published packages are the 854 shipping packages that are published plus the 292 mirror-only ones. The 19 shipping packages that are not published are build intermediates, described under *Known limitations*. The build proceeds in tiers, in this order: `toolchain`, `core`, `base`, `desktop`, `extra`, `compute`, `ai`; the kernel is built in `core`. A tier's default decides whether its packages ship on the image or are mirror-only, and individual packages override that default in either direction — so the tier is the rule, not the shipped reality. The `compute` tier, which holds the GPU compute stack, is mirror-only in full. --- ## What changed since R001.3 The full record is the `[R001.4]` section of `CHANGELOG.md` on `master` in the source repository. The shape of the release: **The certificate bundle** — described at the top of these notes. **The assistant asks before anything leaves the machine, and says what actually ran.** Web searches run only when you ask for one or accept the assistant's offer. Network requests need your review unless you asked directly and the conversation has read no outside content. Fetched content that tries to direct the assistant is held for review before the model sees it, and withheld when review is unavailable. Cloud assistance sends nothing when it is disabled. Approval cards show the command that will actually run, each privileged call asks for administrator authentication and names the action, and a refused action says why it did not run. Answers improved on follow-up requests, package actions, security-state questions and web search results, and the assistant no longer reports an installation as complete without command output that supports it. **The installer** acts only on the disk it validated and stops if that disk changes, shows the Secure Boot key-enrollment notice during installation, and shows a count and a moving bar while it checks every installed file at the end of an installation, where it used to show a still screen. **Package recovery and downloads.** pkm installs a local archive from the bytes it verified, prints one clear next step after a failed installation, and keeps download progress and post-install hook output visible while they run. The helpers that fetch applications from their vendors say plainly that nothing was installed when a download or unpacking step fails, and name what they left behind. **Hardware and the desktop.** Affected ASUS keyboards register their backlight device again, through a fix carried in the kernel package. The Welcomer states the detected graphics card above its optional offers. Users can submit scheduled one-time jobs with `at` again. --- ## Every package changed in R001.4 Every recipe whose version or release differs from R001.3: 28 packages, 27 of them published on the mirror. "Image" means the package also ships on the installation image. | Package | R001.3 | R001.4 | Where | Why | |---|---|---|---|---| | `ca-certificates` | 2026.04.30-3 | 2026.10.20-4 | image, mirror | The Mozilla CA bundle snapshot of 20 October 2026 — the certificate fix. | | `linux-kernel` | 6.18.51-10 | 6.18.51-11 | image, mirror | Affected ASUS keyboards register their backlight device again (the upstream stable keyboard-handshake fix, carried as a declared patch). | | `linux-kernel-pass2` | 6.18.51-11 | 6.18.51-12 | image only | The same fix in the image's second kernel build; a build intermediate, never published. | | `systemd` | 259.1-7 | 259.1-8 | image, mirror | System service authorization follows per-operation approval; the build rejects an unrecognized packaged policy declaration. | | `intergenos-base-files` | 1.0.0-37 | 1.0.0-38 | image, mirror | Declares the R001.4 release identity. | | `pkm` | 0.2.0-113 | 0.2.0-114 | image, mirror | Visible download progress and hook output; a local archive installed from the bytes it verified; clearer recovery steps. | | `intergen` | 0.1.0-338 | 0.1.0-343 | image, mirror | The assistant's consent, review and answer fixes described above. | | `forge` | 1.0.0-364 | 1.0.0-370 | image, mirror | The installer: privileged service limited to installation media, the validated disk rechecked, the enrollment notice, the installed-file check's count and bar. | | `gdm` | 49.2-7 | 49.2-8 | image, mirror | A saved monitor layout is copied to the login screen only from the file that was checked, and its settings stay private. | | `intergen-toggle` | 1.0-5 | 1.0-6 | image, mirror | Describes local processing and each condition under which a request leaves the machine. | | `intergen-welcome` | 1.0-56 | 1.0-58 | image, mirror | States the detected graphics card; describes what leaves the machine. | | `intergenos-backup` | 1.0-30 | 1.0-31 | image, mirror | Restores only checked files, verifies restored bytes before replacing anything, keeps backup stores private. | | `intergenos-helper-lib` | 1.0.0-17 | 1.0.0-18 | image, mirror | Shared download progress for the application helpers; helper metadata read with an isolated Python interpreter. | | `intergenos-wiki` | 1.0.0-17 | 1.0.0-18 | image, mirror | The offline wiki and its signed page manifest advance to the 18 October 2026 render. | | `at` | 3.2.5-6 | 3.2.5-7 | mirror | Users can submit scheduled one-time jobs again. | | `cuda-toolkit` | 13.3.1-11 | 13.3.1-12 | mirror | Shared download progress; footprint metadata written with an isolated Python interpreter. | | `nvidia` | 580.159.04-20 | 580.159.04-21 | mirror | Each installation step shown with its elapsed time and logged once. | | `steam` | 1.0-10 | 1.0-11 | mirror | A failed lookup, download or unpacking step says nothing was installed and names what it left behind. | | `brave` | 1.0-6 | 1.0-7 | mirror | As for `steam`. | | `chatgpt` | 1.0-4 | 1.0-5 | mirror | As for `steam`, with shared download progress. | | `chrome` | 1.0-7 | 1.0-8 | mirror | As for `steam`, with shared download progress. | | `claude-code` | 1.0-15 | 1.0-16 | mirror | Shared download progress for its editor extension. | | `codex` | 1.0-7 | 1.0-8 | mirror | Shared download progress for its editor extension. | | `edge` | 1.0-6 | 1.0-7 | mirror | As for `steam`. | | `ge-proton` | 11.1-9 | 11.1-10 | mirror | As for `steam`, including a compatibility-tool directory already created. | | `signal` | 1.0-6 | 1.0-7 | mirror | As for `steam`. | | `spotify` | 1.0-6 | 1.0-7 | mirror | As for `steam`. | | `vscode` | 1.0-8 | 1.0-9 | mirror | As for `steam`; refuses a package without its data archive. | --- ## Upgrading from R001.3: two known issues - **The kernel can be reported as not finished.** `pkm upgrade --all` can end by reporting `linux-kernel` as not finished, with `FATAL: 2 staged module trees under /usr/lib/modules — refusing to guess which release to depmod`. The message is a false alarm from the kernel package's own install script, which still finds the previous kernel's module directory: the new kernel is installed, signed, set as the boot default, and its module index is built. Do not roll back; `pkm reinstall linux-kernel` repeats the same message. `pkm list` shows the kernel as not finished until a later kernel update replaces it. - **The version shown stays R001.3.** `/etc/os-release` keeps saying R001.3 (Settings → About, `hostnamectl`), and the upgrade lists `/etc/os-release.pkmnew` for review, because the installer recorded the installation medium in that file and the package manager treats that as your own edit. If you have not edited the file yourself, take the new identity and keep the medium line with: ```sh sudo sh -c 'grep "^IMAGE_VERSION=" /etc/os-release >> /etc/os-release.pkmnew; mv /etc/os-release.pkmnew /etc/os-release' ``` If you have edited it, compare the two files first: `diff /etc/os-release /etc/os-release.pkmnew`. --- ## Installing Boot the image and choose **Install InterGenOS (Graphical)** from the boot menu. The installer writes nothing to disk until you confirm on its review screen. **On real hardware:** write the ISO to a USB stick of at least 16 GB. Confirm you have the right device before writing, and verify the stick by reading it back afterwards. **In a virtual machine:** enable EFI firmware — InterGenOS is UEFI-only. Allocate 8 GB of memory, 4 processor cores, and a disk of 35 GB or larger for a representative evaluation — the installer refuses a target disk smaller than 32 GiB. The system boots with as little as 4 GB and 2 cores, but the desktop and the assistant are noticeably slow at that floor. Do not install VirtualBox Guest Additions: the kernel is locked down and rejects unsigned out-of-tree modules by design. On VMware, use the distribution's `open-vm-tools` package rather than the bundled VMware Tools. In a virtual machine the assistant runs its 2-billion-parameter tier. The larger tiers need a discrete GPU passed through to the guest, which most virtual-machine setups do not provide, so a VM exercises the entry tier regardless of how much memory it is given. --- ## Known limitations These are stated so you meet them here rather than in the middle of an install. The assistant's own known limits for this release are listed under *Known limits in R001.4* in `CHANGELOG.md`, with the upgrade notes above. - **Nineteen components on the image have no published binary archive.** They are build-stage intermediates — names ending in `-pass1`, `-pass2`, or `-bootstrap`, such as `systemd-pass2` and `linux-kernel-pass2` — that exist because the from-source bootstrap builds certain packages more than once, at different stages, with different capabilities available. Their files are on the image and they are listed in the software bill of materials for this release, but the mirror deliberately does not publish build intermediates, so those nineteen entries carry no downloadable binary archive and no index checksum. Every other shipped package is published and covered by the index signature. - **In a virtual machine, powering off can record failures** for the display manager and the compressed swap device; neither occurred on the evaluation hardware. - **The `compute` tier is mirror-only in full.** The GPU compute stack is not on the installation image; install it from the mirror after installation. - **Source archives are attested through the index, one level removed.** The signed index records the digest of each published package's source archive, so verifying a source archive is a checksum comparison against the signed index row rather than a signature check on the archive itself; the 48 source archives that belong to build intermediates and toolchain staging definitions have no index row and are not covered. - **Virtual machines may log a cosmetic display message.** Both VirtualBox and VMware can log `failed to create vmw_framebuffer: -22` in the live session. The display works normally. - **On high-DPI hosts under VirtualBox**, set the display resolution manually after first boot. --- ## Support model InterGenOS is a curated rolling distribution with a single supported line. The latest release is the supported release; installed systems move forward with `pkm upgrade --all` from the mirror, and installation images are refreshed at each point release. There are no maintenance branches and no backports — fixes reach users by advancing the supported line, so every user runs the package set the project actually evaluates. R001.4 supersedes R001.3 as the supported release. Nothing reaches the mirror or the installation image without a rebuild, an installation, and an evaluation on real hardware. --- ## Sources The mirror publishes 1,152 source archives under `https://repo.intergenos.org/x86_64/current/sources/`, and the publish pipeline refuses to publish a binary whose source archive is not staged alongside it — unless that package declares no upstream source at all. Counted against the signed index: 1,104 of the 1,146 published binaries have a source archive matching them by name, version and release, and the index carries each one's digest. The remaining 42 are packages with no upstream source to publish — the project's own configuration, branding, font and theme packages, the meta-packages that install a set of other packages, and the helper recipes that fetch a proprietary application from its vendor at install time rather than building it; the publisher prints every one of them by name. The corpus also contains 48 source archives with no corresponding published binary: the build-stage intermediates described under *Known limitations* and the toolchain's staging definitions, whose source is published even though their built binary is not. Source archives are byte-reproducible: regenerating one from the same inputs produces an identical file. The build system that produced this release is in the source repository, along with the recipe for every package. Reproduction instructions are in `SOURCES.md`. --- ## Verification artifacts published with this release | Artifact | Location | |---|---| | Installation image | `repo.intergenos.org/iso/intergenos-r001.4.iso` | | Image checksum | `repo.intergenos.org/iso/intergenos-r001.4.iso.sha256` | | Signature over the image checksum | `repo.intergenos.org/iso/intergenos-r001.4.iso.sha256.asc` | | Release public key | `repo.intergenos.org/keys/intergenos-release-key.asc` | | Signed package index | `repo.intergenos.org/x86_64/current/InterGenOS.db` + `.sig` | | Signed source tag | `R001.4` in the source repository | | Software bill of materials | `intergenos-r001.4.sbom.spdx.json` — SPDX 2.3, 873 shipped packages plus one entry for the image; all 873 carry a SHA-256; of the 854 that the signed index lists, 854 match it | | Published advisories at shipped versions | `advisories-r001-4.html` — the per-package list from this release's pre-build scan, with each advisory's severity — served beside this image and published at https://intergenos.org/advisories/r001-4.html | | Provenance index | `PROVENANCE-R001.4.md` | --- ## Legal InterGenOS is assembled from software under many licenses. The bill of materials lists the license declared by each shipped package. The project's own code is licensed as stated in the source repository. Proprietary applications that `pkm` can fetch are downloaded from their vendors under those vendors' terms and are not redistributed by this project.