# SHA256 integrity vs code signing

## Current POC posture (build 88 readiness)

Nexus auto-update uses **SHA256 checksum verification** only:

- Manifest publishes `artifact.sha256` (and legacy `sha256`).
- Client downloads the ZIP and compares computed hash before install.
- Mismatch blocks installation and is logged to `update.log`.

This protects against **accidental corruption** and **wrong-file CDN mistakes** when the manifest and object stay in sync.

## What SHA256 does not provide

SHA256 is **not** authenticity or trust:

- Anyone who can publish to the CDN can publish a matching manifest + ZIP.
- There is no publisher identity, no tamper-evident chain, and no Windows SmartScreen trust from SHA256 alone.

## Recommended production path

| Layer | Purpose |
|-------|---------|
| Authenticode / EV code signing on `NexusSetup.exe` | OS-level publisher trust |
| Manifest `signature` field (Ed25519 or CMS) | Prove manifest was issued by RenNinja |
| TLS + pinned CDN origin | Reduce MITM on fetch |
| Optional: signed inner ZIP manifest | Bind package hash to publisher key |

The `signature` field exists in the schema but is **null in POC** and not validated by the client.

## Decision for this sprint

**PASS** for integrity checking (SHA256).  
**PENDING** for publisher authenticity (signing not implemented).
