# InterGenOS R001 — Provenance Index

**What this document is.** An index of where every published piece of InterGenOS R001
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-08-18. If you run the same command and get a different answer, the divergence is
the finding — not this document.

---

## 1. The source of record

The tree R001 was built from is a single commit, and that commit is signed.

| Item | Value |
|---|---|
| Repository | `https://github.com/InterGenJLU/intergenos.git` |
| Signed tag | `R001` |
| Tagged commit | `7716421faea22c9e65eaf63207706d4bc717c02a` |
| Tag signature | Good, by signing subkey `D7AA641D81ACD690C5AD865E7276E14DD8886BFE` |
| Signing primary key | `5597A3E0587B253006D0DD7B8C50826182083050` |
| `packages/` tree object | `137deb9f42fbb9951b9848ae22598aee08dc5f92` |

**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
```

**Verify that the package definitions you are reading are the ones the release was
built from** — this is the check that matters if you clone `master` rather than the
tag, because `master` has moved ahead of the tag by two documentation commits:

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

Both print `137deb9f42fbb9951b9848ae22598aee08dc5f92`. The two commits `master`
carries beyond the tag — the README download block and `docs/release-policy.md` —
change no package definition, no build script, and no build-system code:

```sh
git diff --stat R001 master
# README.md              |  4 ++++
# docs/release-policy.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++
```

**A limit, stated plainly.** The signed tag covers the source import commit only.
Neither the README download block nor the release-policy document is inside the
signature. If you verify the tag and then read files from `master`, you have verified
the package definitions and build system but not those two documents.

---

## 2. The installation image

| Item | Value |
|---|---|
| URL | `https://repo.intergenos.org/iso/intergenos-r001.iso` |
| Size | 10,411,311,104 bytes |
| SHA-256 | `1beeb90539bc1031ad135148f379e97a1830b835350f9c7924fd7b9fc3db07c7` |
| Checksum file | `https://repo.intergenos.org/iso/intergenos-r001.iso.sha256` |
| Checksum file SHA-256 | `3802a9f4f930ace3e6c53bb96ba23df98eae3afd78d70d596a53ed54e694c525` |
| Signature over the checksum file | `https://repo.intergenos.org/iso/intergenos-r001.iso.sha256.asc` |
| Signature SHA-256 | `b3034cad429abb0d04704912cc6d88e773f66210c92440b642dec9cf317b7e07` |
| Signature made | 2026-08-18 17:28:12 CDT, by subkey `D7AA641D…` |
| Server `Last-Modified` (image) | Sun, 16 Aug 2026 01:09:07 GMT |

**The image checksum is signed.** Signing the image checksum is the project's
standing practice for every release. The signature is a detached armored signature
over the served checksum file, made by the same signing subkey that signs the release
tag and the package index — so the image's identity is anchored to the same key as
everything else here, not merely to whatever the mirror serves.

**Verify, signature first:**

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

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

The image served at that URL was downloaded in full and hashed for this index; the
computed digest equals the digest in the served checksum file, and the byte count
equals the `Content-Length` the server advertises. The signature over that checksum
file was fetched and verified against the release key, independently of the party
that produced it.

**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 7.

---

## 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 | `17ea737dd64d33a656eb7ca48f3c64d69a80bb2b54c2b4fcf19f1159071b28bb` |
| Signature SHA-256 | `036e82ad7c8d7f49962158a9dddd404dacfdc81a9a29cb79be3dc01d41d942a0` |
| Index generated | 2026-08-17T01:30:15Z (from the index's own `generated` field) |
| Signature made | 2026-08-16 20:30:16 CDT, by subkey `D7AA641D…` |
| Packages in index | 1,105 |
| 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)"`.

**Verify any single package against the index:**

```sh
gzip -dc InterGenOS.db | python3 -c '
import json,sys
db = json.load(sys.stdin)
e  = db["packages"]["bash"]
print(e["filename"], e["version"], e["release"], e["sha256"])'
curl -O https://repo.intergenos.org/x86_64/current/bash-<version>.igos.tar.gz
sha256sum bash-<version>.igos.tar.gz
```

Every index entry also carries `tier`, `license`, `installed_size`, `build_date` and
the package's declared dependencies, so the index alone answers "what is this, where
does it sit, and what does it need" without downloading anything.

---

## 4. The source-archive corpus

Every package built from upstream source has its source published beside the binary,
in a reproducible archive.

| Measurement | Value |
|---|---|
| Source archives published | 1,126 |
| Published binaries in the signed index | 1,105 |
| Binaries with a name-and-version-matching source archive | 1,066 |
| Binaries with no matching source archive | 39 |
| Source archives with no corresponding published binary | 60 |

**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                      # 1126

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 = {f"{n}-{e[\"version\"]}-{e[\"release\"]}.igos.src.tar.gz" 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 39 are.** Packages that declare no upstream source, so there is nothing to
publish: the project's own configuration, branding, font and theme packages
(`intergenos-base-files`, `intergenos-default-settings`, `intergenos-grub-theme`,
`font-inter`, `cybernetic-icon-theme`, and similar), the project's own application
packages, and the helper recipes that fetch a proprietary application from its vendor
at install time rather than building it (`brave`, `chrome`, `claude-code`, `discord`,
`edge`). 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 60 are.** Build-stage intermediates — names ending `-pass1`, `-pass2`,
`-core`, `-tmp` or `-bootstrap`. 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.

**Reproducibility.** Source archives are written deterministically — sorted member
walk, pinned member timestamps, normalised ownership, pinned archive format — so
regenerating one from the same inputs produces a byte-identical file. Each archive
carries a per-input `.sha256` whose value was checked against the recipe's pin when
the archive was written, plus a `README.SOURCES` describing how to reproduce that
package.

**A limit, stated plainly.** The signed index covers binary archives. Source archives
are not listed in it and are therefore not covered by its signature. Verifying a
source archive is a checksum comparison against the pins inside it and in the recipe,
not a signature check.

---

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

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 the `R001` tag and the package index |
| Subkey | `81DD223F9BA9B3F2AFBFFC5AFA24B042975F775E` | Signing |
| Subkey | `B34D3D3FB5EADFC480EDBDB0D3C5DF2CC73B67ED` | Signing |
| Subkey | `99B3E7555064180DC9CE328432AEE44115DEAAED` | Signing |
| Subkey | `62C7E2C30908823DAF5E4EBF917B649E00F2868C` | Encryption |

The primary key is RSA-4096, created 2026-05-05. The signing subkeys carry an
expiry of 2028-05-04.

**Compare the three sources yourself:**

```sh
for src in \
  "https://repo.intergenos.org/keys/intergenos-release-key.asc" \
  "https://keys.openpgp.org/vks/v1/by-fingerprint/D7AA641D81ACD690C5AD865E7276E14DD8886BFE" \
  "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xD7AA641D81ACD690C5AD865E7276E14DD8886BFE" ; do
    curl -sS "$src" | gpg --show-keys --with-fingerprint --with-subkey-fingerprint
done
```

All three print the same primary fingerprint and the same six key components.

**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.sbom.spdx.json` |
| Format | SPDX 2.3, JSON |
| Package entries | 856 shipped packages, plus one entry describing the ISO itself |
| Excluded from the shipped set | 294 package definitions that resolve to mirror-only — 268 of them published in the signed index, 26 build-stage intermediates that are never published |
| Entries carrying a SHA-256 | 837 of 856 |
| Entries with no SHA-256 | 19 — the build intermediates of section 4, which have no published binary archive to hash |
| Generated by | `scripts/iso-sbom-gen.py`, from the source tree at the `R001` tag |

**The checksums in this bill of materials agree with the signed index.** Each of the
837 hashes was produced by hashing the archive downloaded from the mirror, and each
was then compared against the digest for that package inside the GPG-signed index:
837 equal, 0 differing, 0 names absent from the index. So the bill of materials
inherits the index signature's attestation rather than making an independent claim.
Reproduce that comparison:

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

The shipped set is not a hand-maintained list and not a filename pattern. 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 — an SBOM
that quietly omits a shipped package would be a false claim of completeness.

**The shipped and mirror-only counts do not subtract into the tree total, and here is
why.** The same tool the build pipeline uses to decide what to evict from the image
reports 856 shipped and 294 mirror-only against 1,153 definition directories. The
remaining 19 directories are early-bootstrap variants that build a package a second
time under a `-core` name and ship no archive under that name. In the other
direction, the shipped total is 856 rather than 840 because sixteen packages from the
earliest bootstrap stage — `binutils`, `gcc`, `coreutils`, `util-linux` and similar —
ship under a name with no separate definition directory. Counted as sets rather than
by subtraction: 840 shipped definitions + 294 mirror-only definitions + 19 `-core`
variants = 1,153.

**Reproduce the split, and its relation to the signed index:**

```sh
python3 scripts/derive-iso-exclusions.py --mode=names \
        --packages ./packages --output mirror-only.txt
# ISO packages: 856      MIRROR packages: 294

grep -v '^#' mirror-only.txt | sort > mirror-only-names.txt
gzip -dc InterGenOS.db > db.json
python3 -c '
import json
idx   = json.load(open("db.json"))["packages"]
names = [n.strip() for n in open("mirror-only-names.txt") if n.strip()]
inidx = [n for n in names if n in idx]
print("mirror-only definitions   :", len(names))   # 294
print("  published in the index  :", len(inidx))   # 268
print("  never published         :", len(names) - len(inidx))'  # 26
```

The 26 that are never published are toolchain-stage intermediates: `bash-tmp`,
`binutils-pass1`, `binutils-pass2`, `gcc-pass1`, `gcc-pass2`, `libstdcpp`,
`linux-headers`, `mingw-w64-gcc-bootstrap`, and the remaining `*-tmp` names. The
1,105 entries in the signed index are the 837 published shipped packages plus these
268 published mirror-only packages.

**Regenerate it:**

```sh
git clone https://github.com/InterGenJLU/intergenos.git && cd intergenos
git checkout R001
python3 scripts/iso-sbom-gen.py --output sbom.json \
  --iso-tag "intergenos-r001.iso sha256:1beeb90539bc1031ad135148f379e97a1830b835350f9c7924fd7b9fc3db07c7"
```

---

## 7. 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 are not covered by the index signature.** See section 4.
- **Two commits on `master` sit outside the signed tag.** See section 1.
- **The bill of materials describes the package set the ISO ships, derived from the
  package definitions — not an inventory taken by opening the ISO's filesystem.**
  Those two answer the same question from different directions, and only the first is
  claimed here.
- **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.