# Implementation Plan: 2026-09-01 Security Assessment Remediation

## Overview

Resolve every open finding in `docs/peach-android-independent-security-assessment-2026-09-01.pdf`
against the current v2.14.89 tree. Work is ordered by release risk, delivered as small Koh saves,
and kept separate from the deferred PIN hardware-validation queue.

## Architecture Decisions

- Treat `local.properties` as SDK configuration only. Release signing secrets must arrive through
  protected environment injection, and release builds fail closed when the required inputs are absent.
- Permit external URL dispatch only for canonical HTTPS URLs. Bare hosts normalize to HTTPS; HTTP and
  all non-web schemes are rejected.
- Authenticate update metadata before trusting any manifest field, using a pinned offline verification
  key and a versioned signed envelope. Existing APK checksum, identity, version, and signer-lineage gates remain.
- Keep release logging to opaque, redacted event identifiers. Debug builds may retain diagnostic detail.
- Preserve favicon opt-in but require informed consent naming the provider and disclosure scope; validate
  domains and cache containment inside the favicon helper itself.
- Pin the Rust toolchain and verify the native build provenance without introducing a new dependency.

## Task List

### Phase 1: Release-root blockers

- [ ] PB-26-025: remove plaintext signing secrets and investigate exposure/rotation.
- [ ] PB-26-026: enable and validate R8 plus resource shrinking.
- [ ] PB-26-027: restrict external URL opening to canonical HTTPS.

### Checkpoint: Release blockers

- [ ] Fresh-workspace release signing uses protected injection only.
- [ ] Shrunk release builds and critical device flows pass.
- [ ] Hostile and non-HTTPS URI tests pass.

### Phase 2: Integrity and privacy boundaries

- [ ] PB-26-028: require independently signed update metadata.
- [ ] PB-26-029: remove debug credential literals from production source/package.
- [ ] PB-26-030: add informed favicon consent and opt-out network proof.
- [ ] PB-26-031: enforce redacted release logging.

### Checkpoint: Integrity and privacy

- [ ] Forged, stale, rollback, alternate-URL, and key-rotation update cases are covered.
- [ ] Release APK contains no demo credential literals.
- [ ] Opt-out produces no favicon requests; opt-in copy names DuckDuckGo and inventory disclosure.
- [ ] Malformed sync/pairing inputs emit only approved opaque release events.

### Phase 3: Supply-chain and helper hardening

- [ ] PB-26-032: pin Rust and native build provenance.
- [ ] PB-26-033: validate favicon hosts and canonicalize cache paths at the helper boundary.

### Checkpoint: Complete

- [ ] Full JVM tests, lint, release build, and applicable instrumentation/smoke gates pass.
- [ ] Release artifacts are inspected for shrinking, credential literals, signer identity, and native provenance.
- [ ] Every finding has a resolution record, Koh save, validation evidence, and residual-risk statement.
- [ ] The original PIN hardware-validation queue remains unchanged for follow-up.

## Finding Resolution Details

### PB-26-025 - Signing credentials

**Acceptance criteria:** no signing password or keystore path is read from `local.properties`; local-only
configuration is ignored; missing protected inputs cannot silently produce a publishable release; a sanitized
history/workspace search is recorded. Rotation, revocation, backup/CI review, and old-signer disposition are
owner actions and must not be falsely marked complete from source changes alone.

**Verification:** configuration tests or Gradle task checks cover missing/present injection; `koh diff` contains
no secret value; a fresh-workspace release build path is documented and exercised where credentials are available.

**Likely files:** `.gitignore` or Koh ignore configuration, `app/build.gradle`, release documentation.

### PB-26-026 - Release shrinking

**Acceptance criteria:** release enables `minifyEnabled` and `shrinkResources`; narrow project keep rules exist;
security-sensitive reflection/serialization paths continue working.

**Verification:** unit, lint, release, APK inspection, and device smoke tests for unlock, autofill, passkeys,
updates, crypto/import, and sync/pairing.

**Likely files:** `app/build.gradle`, `app/proguard-rules.pro`, focused tests/documentation.

### PB-26-027 - External URL allowlist

**Acceptance criteria:** bare valid hosts and HTTPS normalize safely; HTTP, `intent:`, `file:`, custom schemes,
malformed authorities, credentials, control characters, and encoded separator attacks do not reach ACTION_VIEW.

**Verification:** focused pure unit tests first, then compile and a manual open-link smoke test.

**Likely files:** `AdditionalUrlsDetail.kt`, a focused JVM test.

### PB-26-028 - Signed update metadata

**Acceptance criteria:** a versioned signature covers the exact trusted manifest bytes; verification uses a pinned
public key before parsing URLs/checksums/notes; unknown keys, invalid signatures, stale metadata, and rollback fail closed.

**Verification:** deterministic signature vectors plus forged HTTPS, key transition, alternate URL, stale, and rollback tests.

**Dependencies:** release-side offline signing key and manifest signing step must be available before completion.
The current local architecture spans three repositories: Koh publishes the artifacts, Kepr persists and serves
the release record, and Peach verifies it. Koh's updater already defines a per-platform Ed25519 envelope shape,
but the build/offer path does not produce those signatures and Kepr's generic endpoint does not persist or emit
them. Reuse that shape only after defining one canonical byte payload and a production key-custody boundary.
The public Kepr service must not hold the offline private key.

**Likely files:** `UpdateRepository.kt`, manifest model/tests, Kepr build/release scripts and documentation.

### PB-26-029 - Debug seed isolation

**Acceptance criteria:** predictable usernames, passwords, and TOTP seeds leave production source; debug QA data
is generated at runtime or isolated under debug/test sources; release artifact string/symbol inspection is clean.

**Verification:** debug seed behavior test plus release APK scan.

**Likely files:** `VaultListViewModel.kt`, debug source-set helper, focused tests.

### PB-26-030 - Favicon consent

**Acceptance criteria:** enabling site icons requires explicit copy naming DuckDuckGo and explaining one request
per distinct vault domain; declining or disabling causes no network requests; prior opt-ins are re-consented after the copy change.

**Verification:** settings-state tests, UI test where practical, and network-capture/fake-client proof of zero opt-out requests.

**Likely files:** settings model/UI, `VaultListScreen.kt`, favicon tests and privacy documentation.

### PB-26-031 - Release logging

**Acceptance criteria:** production sync/pairing logs contain only allowlisted opaque event names and redacted
error classes; payloads, peer identifiers, protocol material, raw exception messages, and stack traces are excluded.

**Verification:** logger unit tests and a release log capture under malformed inputs.

**Likely files:** sync logging helper and the three reported sync/adoption call sites.

### PB-26-032 - Rust provenance

**Acceptance criteria:** Rust channel/version and target inputs are pinned; Cargo uses the lockfile; produced native
artifacts have recorded source/toolchain/target hashes or equivalent reproducible provenance.

**Verification:** pinned-toolchain build and provenance output comparison.

**Likely files:** `rust-toolchain.toml`, root `build.gradle`, native build/release documentation.

### PB-26-033 - Favicon cache containment

**Acceptance criteria:** helper accepts only canonical validated DNS hosts; every hit/miss cache path remains a direct
child of the favicon cache directory; invalid caller material cannot create, read, or write another path.

**Verification:** traversal, separator, Unicode/control, malformed-host, and valid-IDN/domain unit tests.

**Likely files:** `Favicons.kt`, focused tests.

## Risks and Mitigations

| Risk | Impact | Mitigation |
|---|---|---|
| Signing credentials may already exist outside this workspace | Source cleanup cannot revoke compromise | Keep release blocked until the owner completes rotation/exposure review |
| R8 removes reflected or JNI-reached code | Runtime-only regression | Start with narrow rules, inspect mapping/usage, and run device smoke gates |
| Signed metadata requires release-channel coordination | Client-only change could block all updates | Land signer tooling and client verification as one coordinated, rollback-tested unit |
| Re-consent reduces favicon adoption | Expected privacy tradeoff | Use concise, explicit copy and preserve initials fallback |
| Log reduction hurts diagnostics | Production failures become harder to investigate | Retain opaque event IDs and detailed debug-only logs |

## Open Questions

- The release-signing values' exposure beyond this machine, rotation capability, and old-signer disposition are UNCONFIRMED.
- The offline update-metadata signing key custodian and Kepr manifest-signing integration are UNCONFIRMED.
- Physical-device availability for the R8 and release-log smoke matrices is UNCONFIRMED.