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

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.