# InterGenOS R001.3 — Provenance Index

**What this document is.** An index of where every published piece of InterGenOS
R001.3 comes from, and how to check that claim yourself. Every row states a measured
value and the exact command that produces it. Nothing here asks you to take the
project's word for anything: each entry is either something you can recompute, or it
is marked as a limit of what this release can prove.

**How the values were measured.** Every number below was produced by running the
stated command against the published artifacts over the public network, on
2026-10-18. If you run the same command and get a different
answer, the divergence is the finding — not this document. Section 6 is where that
covenant was exercised against this release's own bill of materials; section 7 records
the twenty packages this release republished under an unchanged version and release,
with the signed record that names them.

---

## 1. The source of record

The tree R001.3 was built from is a single commit on `master`, and that commit is
signed by an annotated tag.

| Item | Value |
|---|---|
| Repository | `https://github.com/InterGenJLU/intergenos.git` |
| Signed tag | `R001.3` |
| Tag object | `c17c4c67ffd68871fd439146891f6c5b4084fa92` |
| Tagged commit | `734c92e6978aede384877e58dcc39f1fe1ef97c9` — the release head `dcc68d525ab227e7d05d6b983ee512c9b880cd02` (the image was built from it) plus the public-words commit (the CHANGELOG section and the README download block) and the pre-push hook correction; neither later commit touches `packages/` |
| Tag signature | Good, by signing subkey `D7AA641D81ACD690C5AD865E7276E14DD8886BFE` (verified with `git verify-tag R001.3` at the tag) |
| Signature made | 2026-10-18T19:16:08-05:00 |
| Signing primary key | `5597A3E0587B253006D0DD7B8C50826182083050` |
| `packages/` tree object | `8341963113963aca03a8532cc3c5f9d0449231cf` (re-read at the tag; equal to the release head's) |
| Preceding release tag | `R001.2`, at commit `0ca4650224d1b83afc70fb7f8af46b19cee1905b` |
| Preceding major release tag | `R001`, at commit `7716421faea22c9e65eaf63207706d4bc717c02a` |

**Verify the tag:**

```sh
git clone https://github.com/InterGenJLU/intergenos.git && cd intergenos
curl -sS https://repo.intergenos.org/keys/intergenos-release-key.asc | gpg --import
git tag -v R001.3
git ls-remote --tags https://github.com/InterGenJLU/intergenos R001.3
```

**Verify that the package definitions you are reading are the ones this release was
built from.** The `packages/` tree object is the thing to compare, because it is
unchanged by commits that touch documentation only:

```sh
git rev-parse R001.3:packages
git rev-parse master:packages
```

Both print `8341963113963aca03a8532cc3c5f9d0449231cf`. Every count in section 6 was
derived against that exact tree object.

**A note on what the tagged tree contains.** The tagged commit is the tree the
published packages and the image were built from, plus the release's documentation
(the dated changelog section and the download block). No package definition on the
tag differs from what the mirror serves.

**A limit, stated plainly.** The tag pins the source tree; it does not attest the
machine that compiled it. See section 8.

---

## 2. The installation image

| Item | Value |
|---|---|
| URL | `https://repo.intergenos.org/iso/intergenos-r001.3.iso` |
| Size | 10,487,570,432 bytes |
| SHA-256 | `098c8747deedc14c7d844b8047cfa239c655381b1614c950e3a676dcae53f256` |
| Checksum file | `https://repo.intergenos.org/iso/intergenos-r001.3.iso.sha256` |
| Checksum file SHA-256 | `e3383b79a39b5ea55e4fe9caa179bcc0f68b2882bb42d2c941047a27c1bdd82a` |
| Signature over the checksum file | `https://repo.intergenos.org/iso/intergenos-r001.3.iso.sha256.asc` |
| Signature SHA-256 | `262f4623d2bdc04c0349b748c2bf4423d71ecd228400dd6d604b9650f7e15875` |
| Signature made | Sun 18 Oct 2026 06:46:56 PM CDT, by subkey `D7AA641D…` |
| Server `Last-Modified` (image) | `Sun, 18 Oct 2026 23:44:32 GMT` |

**Verify, signature first:**

```sh
curl -O https://repo.intergenos.org/iso/intergenos-r001.3.iso
curl -O https://repo.intergenos.org/iso/intergenos-r001.3.iso.sha256
curl -O https://repo.intergenos.org/iso/intergenos-r001.3.iso.sha256.asc

gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg
gpgv --keyring ./release-key.gpg \
     intergenos-r001.3.iso.sha256.asc intergenos-r001.3.iso.sha256   # Good signature
sha256sum -c intergenos-r001.3.iso.sha256                            # OK
```

The signature over the served checksum file was fetched and verified against the
release key for this index; the byte count in the table equals the `Content-Length`
the server advertises for the image.

**A second, independent attestation of the same digest.** The image-assembly step
writes a provenance manifest recording the SHA-256 of every input artifact it
consumed — the signed bootloader and the three signed unified kernel images, and the
squashfs — together with the SHA-256 of the image it produced. That manifest
(generated 2026-10-18T15:45:03Z, `SOURCE_DATE_EPOCH` 1792332723) records the output
digest — SHA-256 `098c8747deedc14c7d844b8047cfa239c655381b1614c950e3a676dcae53f256` —
as the same value the published checksum file carries. The two were produced by
different steps at different times: one by the assembler as it wrote the image, one
by the publish path as it staged it. The image was assembled under the working name
`intergenos-r001.3-04.iso` (the fourth candidate of this cycle; the three before it
were destroyed after they failed their evaluations) and is served as
`intergenos-r001.3.iso`; the bytes are the same.

**A limit, stated plainly.** The signature attests the checksum file, not your copy
of the image. Verifying it proves the checksum you are about to compare against is
the project's; comparing the image to that checksum is a separate step you have to
run, and it is the one that catches a truncated download or a substituted image.
Neither step says anything about the machine that built the image — see section 8.

---

## 3. The signed package index

The mirror's index is a signed manifest of the entire repository. One signature
covers every package entry, and each entry carries that package's own SHA-256 — so
verifying one signature transitively attests the bytes of every published package.

| Item | Value |
|---|---|
| Index URL | `https://repo.intergenos.org/x86_64/current/InterGenOS.db` |
| Signature URL | `https://repo.intergenos.org/x86_64/current/InterGenOS.db.sig` |
| Index SHA-256 | `37a9aa3190db46914117e6e2081c0cc598b25b9990daedfb989af843704a9304` |
| Signature SHA-256 | `0e86859252a067e84d880fe7a100d0f6d30646b21692f6bbc2d12b9e4407ea10` |
| Signature made | Sun 18 Oct 2026 05:31:57 PM CDT, by subkey `D7AA641D…` |
| Index generated | 2026-10-18T22:27:31Z |
| Packages in index | 1,146 |
| Entries carrying a SHA-256 | 1,146 of 1,146 |
| Entries carrying a source-archive SHA-256 (`source_sha256`) | 1,104 of 1,146 — the 42 others declare no upstream source |
| Format | gzip-compressed JSON |

**Verify the signature:**

```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 from "InterGenOS Project Signing Key (primary)"`.

**The index describes the bytes the mirror actually serves.** That was checked rather
than assumed, by downloading a published archive and hashing it:

```sh
curl -O https://repo.intergenos.org/x86_64/current/acl-2.3.2.igos.tar.gz
sha256sum acl-2.3.2.igos.tar.gz
# sha256 1ed571ba5da9641fba9a859f41cdf7f35b71a2e1eb07adf2154ab48954c69ddc
gzip -dc InterGenOS.db | python3 -c '
import json,sys; print(json.load(sys.stdin)["packages"]["acl"]["sha256"])'
# sha256 1ed571ba5da9641fba9a859f41cdf7f35b71a2e1eb07adf2154ab48954c69ddc
```

The two agree (re-run 2026-10-18 against the served index: 854 match, 0 differ). Section 6 records the
same comparison run across the whole shipped set.

---

## 4. The source-archive corpus

| Measurement | Value |
|---|---|
| Source archives published | 1,152 |
| Published binaries in the signed index | 1,146 |
| Binaries with a name-version-release-matching source archive | 1,104 |
| Binaries with no matching source archive | 42 |
| Source archives with no corresponding published binary | 48 |

**Reproduce these counts:**

```sh
curl -sS https://repo.intergenos.org/x86_64/current/sources/ \
  | grep -o 'href="[^"]*\.igos\.src\.tar\.gz"' | sed 's/href="//;s/"//' | sort > sources.txt
wc -l sources.txt                      # 1152

curl -sS -O https://repo.intergenos.org/x86_64/current/InterGenOS.db
gzip -dc InterGenOS.db | python3 -c '
import json,sys
db = json.load(sys.stdin)["packages"]
want = {"%s-%s-%s.igos.src.tar.gz" % (n, e["version"], e["release"]) for n, e in db.items()}
have = set(open("sources.txt").read().split())
print("binaries          :", len(db))
print("matched           :", len(want & have))
print("binary, no source :", len(want - have))
print("source, no binary :", len(have - want))'
```

**What the 42 are.** Packages that declare no upstream source, so there is nothing to
publish: the project's own configuration, branding, font and theme packages, the
meta-packages whose whole content is a dependency list, and the helper recipes that
fetch a proprietary application from its vendor at install time rather than building
it. The publish pipeline enforces the correspondence rule and derives this exemption
set from the package definitions themselves at publish time, printing every exempted
name rather than consulting a hidden allowlist.

**What the 48 are.** Build-stage intermediates — names ending `-pass1`, `-pass2`,
`-core`, `-tmp` or `-bootstrap`, plus the toolchain's two staging definitions
`libstdcpp` and `linux-headers`. A from-source bootstrap builds some packages more
than once, at different stages, with different capabilities available. Their source
is published; their built binaries deliberately are not, because a build intermediate
is not a package a user installs.

**New in this release: the index attests the source archives.** Each published
binary's index row that declares an upstream source carries `source_sha256`, the
digest of its source archive, so the index signature now covers the 1,104 source
archives those rows name. Verify one:

```sh
gzip -dc InterGenOS.db | python3 -c '
import json,sys; e=json.load(sys.stdin)["packages"]["acl"]
print(e["source_sha256"], "%s-%s-%s.igos.src.tar.gz" % ("acl", e["version"], e["release"]))'
curl -O https://repo.intergenos.org/x86_64/current/sources/acl-2.3.2-1.igos.src.tar.gz
sha256sum acl-2.3.2-1.igos.src.tar.gz    # equal to the row's source_sha256
```

**A limit, stated plainly.** The 48 source archives that belong to build intermediates
and toolchain staging definitions have no index row and are therefore not covered by
the signature; verifying one of them is a checksum comparison against the pins inside
it and in its recipe.

---

## 5. The release key and where it is served

R001.3 is signed by the same key as R001, R001.1 and R001.2. One primary key, served
from three independent places. All three serve the same key material; the
ASCII-armored bytes differ between them because each keyserver normalises packet
order and strips third-party certifications differently, which is why the fingerprint
— not the file hash — is the thing to compare.

| Location | URL or command |
|---|---|
| Project mirror | `https://repo.intergenos.org/keys/intergenos-release-key.asc` |
| keys.openpgp.org | `gpg --keyserver keys.openpgp.org --recv-keys 5597A3E0587B253006D0DD7B8C50826182083050` |
| keyserver.ubuntu.com | `gpg --keyserver keyserver.ubuntu.com --recv-keys 5597A3E0587B253006D0DD7B8C50826182083050` |

| Key component | Fingerprint | Role |
|---|---|---|
| Primary | `5597A3E0587B253006D0DD7B8C50826182083050` | Certification and signing; **this is the fingerprint to compare** |
| Subkey | `D7AA641D81ACD690C5AD865E7276E14DD8886BFE` | Signed this release's image checksum, package index, corrective record and `R001.3` tag |

The copy served from the project mirror at the time of measurement has SHA-256 `18b15b6fb975f0ab55dc3fd7cc0dc85087619c39354732a90db1c20cb51e7da6`,
unchanged since R001.1 (re-read 2026-10-18 from the served mirror: unchanged). Do not treat that value as the thing to check —
compare the fingerprint, for the reason given above.

**A limit, stated plainly.** Three sources agreeing raises the cost of substituting a
key; it does not by itself prove the key belongs to this project. That is what key
certification is for, and it is your decision to make, not something a release
document can settle on your behalf.

---

## 6. The software bill of materials

| Item | Value |
|---|---|
| File | `intergenos-r001.3.sbom.spdx.json` |
| SHA-256 | `177129e3b744c8f01319d091ff39c4b1c4e3e69df14f6b52ef1293e6061910e1` |
| Format | SPDX 2.3, JSON |
| Created | 2026-10-18T14:12:03Z (from the document's own `creationInfo`) |
| Total entries | 874 |
| — components carrying an archive SHA-256 | 873 |
| — the image record, which carries no archive checksum by design | 1 |
| Generated by | `scripts/iso-sbom-gen.py`, from the tree the image was assembled from |

**The shipped set is derived, not curated.** The generator imports the same parser
the build pipeline uses and reads each package's resolved `iso_include` value, so the
set in the bill of materials and the set the build ships are the same computation and
cannot drift apart. A package that cannot be identified is a loud refusal naming it,
and no document is written at all.

**The checksums in this bill of materials against the signed index.** Measured
against the served index for this document (measured 2026-10-18 against the SERVED index after the publish: 854 / 0 / 19 / 1 — the same figures as against the release candidate's index):

| Result | Count |
|---|---|
| Component checksum equal to the signed index | 854 |
| Component checksum differing | 0 |
| Component absent from the index — never-published build intermediates | 19 |
| Entries with no archive checksum — the image record | 1 |

**Reproduce it:**

```sh
gzip -dc InterGenOS.db > db.json
python3 -c '
import json
sbom = json.load(open("intergenos-r001.3.sbom.spdx.json"))
idx  = json.load(open("db.json"))["packages"]
same = diff = absent = nohash = 0
for p in sbom["packages"]:
    ck = [c["checksumValue"] for c in p.get("checksums", []) if c["algorithm"] == "SHA256"]
    if not ck: nohash += 1; continue
    e = idx.get(p["name"])
    if e is None: absent += 1; continue
    same += ck[0] == e["sha256"]; diff += ck[0] != e["sha256"]
print("equal:", same, " differ:", diff, " absent:", absent, " no checksum:", nohash)'
```

Unlike R001.2, no component differs: nothing was republished after the image was
assembled, so the image's packages and the mirror's are the same bytes.

**Licenses in the bill of materials.** Every component entry carries a
`licenseDeclared` value taken from the package definition — 72 distinct SPDX
identifiers across the set. Every entry's `licenseConcluded` is `NOASSERTION`, which
is the honest SPDX encoding: "declared" is what the package states, "concluded" is
what an analyst determined, and no analyst pass was run. That is a statement of what
was not done, not a gap discovered.

---

## 7. Twenty packages republished at an unchanged version and release

The mirror publisher refuses an archive whose bytes differ from the served one unless
its version or release is strictly newer, so that an installed system can always reach
a changed package through `pkm upgrade`. This release carried twenty packages that the
rule would have refused, and admitted them through the designed exception: a record,
signed by the release key, that names each one with the served and the replacement
digest, which the publisher re-derives and binds into the generated index and the
transparency log.

| Item | Value |
|---|---|
| Record | `record.json`, incident `r0013-rebuilt-same-version-release`, 20 exceptions |
| Record SHA-256 | `ad58002af426ec75989bac030dcaf846df262dd76d473d80cff9c5ea4a574ff5` |
| Signature (`record.json.asc`) SHA-256 | `6eb7d95f2d23bcaeb3510994e1233ab03699fd56777e20ac82076cc64e1ff3bb`, by subkey `D7AA641D…`, 2026-10-18 |
| Where it travels | the mirror's transparency-log entry for this publish `6365c73ac0d9865a360446eee84d32d0abf4fedd` |

**Why the bytes differ.** R001.3 was a targeted rebuild from the R001.2 lineage; the
build rebuilds a package whenever its recipe file changes while the release number
moves only when a build-affecting field changes. Nineteen packages were rebuilt with
their recipe version and release unchanged. Measured archive against archive:

- **Fourteen are payload-identical to the R001.2 archive** — every installed file has
  the same bytes; only the build date inside the archive's metadata differs:
  `bdftopcf`, `blueprint-compiler`, `dart-sass`, `font-cursor-misc`, `font-misc-misc`,
  `gc`, `haproxy`, `influxdb`, `lighttpd`, `mingw-w64-crt`, `mingw-w64-headers`,
  `mingw-w64-tools`, `nv-codec-headers`, `websockets`.
- **Five carry binaries rebuilt from the same pinned sources:** `caddy` (1 program),
  `etcd` (3 programs), `ibus` (2 programs and 30 compiled Python files),
  `mingw-w64-winpthreads` (6 cross-compiled libraries), `wxwidgets` (1 library).
- **`unsloth` moves from 2026.7.4 to 2026.6.2**, the newest release its upstream
  publishes as a source tarball; the 2026.7.4 package could not be rebuilt from its
  declared source by anyone, which the project's corresponding-source commitment does
  not allow.

**What it means for an installed system.** `pkm upgrade` moves a package only to a
newer version or release, so an R001.2 system keeps its installed copies of these
twenty — the same software at the same version. `pkm reinstall <name>` fetches the
current bytes. An installed `unsloth` 2026.7.4 is reported as newer than the index and
left in place; replacing it with 2026.6.2 needs an explicit `--allow-downgrade`.

**A limit, stated plainly.** The five rebuilt binaries were compared byte for byte
against the served ones, not run against them; "the same pinned sources" is what the
recipes and the build record state.

---

## 8. What this release does not prove

Stated here rather than left for you to discover.

- **The image checksum is signed, but the signature covers the checksum file and not
  your copy of the image.** Verifying it and then hashing the image are two separate
  steps, and only running both establishes that the file on your disk is the released
  image. See section 2.
- **Source archives of build intermediates are not covered by the index signature.**
  See section 4.
- **The bill of materials describes the package set the image ships, derived from the
  package definitions — not an inventory taken by opening the image's filesystem.**
  Those two answer the same question from different directions, and only the first is
  claimed here.
- **Twenty packages were republished at an unchanged version and release.** See
  section 7 for what was measured and what was not.
- **This index does not attest the build environment.** It records what was published
  and how to check it. A formal attestation of the machine and toolchain that
  produced the artifacts is a separate mechanism and is not part of R001.3.