Below is a **complete but non-operational threat-surface map** answering exactly what remains modifiable **even after** verifying upstream kernel tarball signatures as done in that PR.

This is purely **defensive / audit-oriented**.

---

## What the PR *does* secure

✔ Upstream kernel **tarball integrity**

* Ensures the `linux-x.y.z.tar.{xz,zst}` is exactly what kernel.org signed
* Prevents CDN tampering or MITM on the base kernel source

This is necessary, but it is **only one layer**.

---

## What can still be modified (and how)

### 1. Patch authenticity (largest remaining risk)

Kernel.org signs **only the base tarball**.
Everything added **on top** remains unsigned unless explicitly handled.

Still modifiable:

* All `*.patch` files in `source=()`
* Patch ordering
* Patch content
* Patch provenance

Why this matters:

* A single patch can alter:

  * `cred.c`
  * syscall tables
  * networking paths
  * LSM hooks
* Patch changes do **not** affect upstream tarball signature validity

Mitigation:

* Patch files stored in repo + peer review
* Prefer patches referencing upstream commit hashes
* Optional: detached GPG signatures for patches (rare, but possible)

---

### 2. Kernel configuration (`.config`)

Config files are **not signed** and are extremely powerful.

Still modifiable:

* Enable/disable LSMs
* Disable audit
* Enable debug backdoors
* Allow unsafe kernel features
* Change module loading rules

Why this matters:

* A “clean” kernel source can still be unsafe via config
* Many kernel hardening decisions live entirely in `.config`

Mitigation:

* Diff `.config` vs upstream distro configs
* Look for silent disables (e.g. `CONFIG_AUDIT=n`)
* Reproducible config generation

---

### 3. PKGBUILD logic itself

`makepkg` executes shell code.

Still modifiable:

* Custom `prepare()`
* Custom `build()`
* Conditional logic
* Environment-dependent behavior

Examples (conceptual, not instructions):

* Conditional patch application
* Build flags differing in CI vs local
* Silent behavior under specific env vars

Mitigation:

* Inspect PKGBUILD functions
* Ensure no network access during build
* Ensure deterministic flags

---

### 4. CI pipeline injection

Even with perfect sources, CI is a **separate trust boundary**.

Still modifiable:

* Extra patches applied only in CI
* Environment-specific flags
* Binary post-processing
* Artifact replacement

Key point:

> **A clean repo does not prove a clean artifact**

Mitigation:

* CI scripts stored in repo
* No opaque CI steps
* Reproducible builds
* User-verifiable rebuilds matching CI hash

---

### 5. Toolchain trust (compiler, linker)

The kernel is only as trustworthy as the toolchain.

Still modifiable:

* Compiler plugins
* LTO behavior
* Hardening flags
* Instrumentation

This is subtle but real (see “trusting trust”).

Mitigation:

* Known compiler versions
* Reproducible builds
* Minimal toolchain surface

---

### 6. Binary distribution layer (after build)

Even if CI is clean:

Still modifiable:

* Repository signing keys
* Package replacement
* Mirror compromise

Mitigation:

* Pacman signature verification
* Key rotation transparency
* Reproducible artifacts

---

## What signature verification does *not* claim to solve

The PR **does not claim**:

* End-to-end supply chain security
* Patch trust
* CI trust
* Reproducibility

And that is normal. It solves **one specific problem**: upstream tarball integrity.

---

## Condensed trust boundary map

| Layer                   | Signed?      | Still mutable? |
| ----------------------- | ------------ | -------------- |
| Upstream kernel tarball | ✔            | ❌              |
| Patch set               | ❌            | ✔              |
| Kernel config           | ❌            | ✔              |
| PKGBUILD logic          | ❌            | ✔              |
| CI pipeline             | ❌            | ✔              |
| Toolchain               | ❌            | ✔              |
| Binary distribution     | ✔ (repo key) | ✔ (key trust)  |

---

## Bottom line

The PR is **correct and valuable**, but it secures **only one layer**.

To answer your question directly:

> **What other ways it could still be modified?**

**Everything above the upstream tarball remains modifiable unless independently audited, reproducible, or signed.**

That is not unique to CachyOS — it is true for **every custom kernel distribution** unless they implement full end-to-end reproducibility and patch signing.

If you want, next we can:

* Classify CachyOS patches by risk level
* Identify which subsystems they touch
* Compare their patch surface vs Arch’s `linux` package

That would give you a concrete risk profile rather than a theoretical one.