chore(local): add local Oracle dev/test harness

[wz-gsa]

Split out of #537 to keep that PR focused on the shipping broker code.

Adds a docker-compose-based local harness for developing/exercising the Oracle work locally. Dev signal only — never compliance evidence (live GovCloud RDS proof is separate).

• moto for the RDS control-plane request-shape smoke.
• gvenzl/oracle-free + an Oracle 19c compose for the SQL hardening/assessment loop.
• A Makefile (doctor/quickstart/unit/moto-smoke); assess -> harden -> assess runs inside the container via docker exec (no host Oracle Instant Client required).
• local/README.md documents the overlay-sibling-clone requirement.

Touches only local/; no application or CI-pipeline changes.

Closes

Closes #529 (WS10/11 — Oracle 19c: SQL hardening package + local test harness). The authoritative SQL lives in the overlay repo; this is the local dev loop for it.

[wz-gsa]

Ran a hostile self-review and fixed the findings (pushed):

• MEDIUM — LAN exposure. All three compose files published ports on 0.0.0.0 (Oracle 1521/1522, moto 5000) with a known local-only password. Now bound to 127.0.0.1 only, with a comment warning not to revert.
• LOW — reports/ not actually gitignored despite the README claiming so. Added local/.gitignore that ignores reports/ (dev-signal output, never commit).
• LOW — dangling references. The init/*.sql seed scripts the README/compose reference weren't actually included, so oracle-up silently didn't seed the non-SYS user + weak state. Added them (force-tracked past the global *.sql ignore).
• LOW — reproducibility. Pinned motoserver/moto:5.2.2 (was :latest).
• Swept ephemeral tokens (ADR/WS/issue refs to docs that live on other branches) out of the local/ comments so nothing dangles.

Verified: compose YAML parses, ports bind loopback-only, reports/ ignored while init/*.sql tracked.

[wz-gsa]

📋 Merge order: 2️⃣ of 4 (local dev/test harness — local/ only, pipeline-inert).
Coordinated set; full order + status board: #550

[pburkholder]

Proposed ADR (for discussion): Drop the local Oracle 19c Enterprise Edition image from the test harness

Posting this as a comment for discussion. If we ratify it, the accepted ADR
should land in docs/adr/0001-*.md per the workspace standard so the rationale
is durable.

---

---
title: "Drop the local Oracle 19c Enterprise Edition image from the test harness"
status: "proposed"
date: "2026-07-23"
decision_makers: ["Peter Burkholder"]
category: "development-tooling"
nist_controls: ["CA-2", "SA-11", "SA-15", "CM-2"]
impact_level: "moderate"
ato_relevance: "no"
risk_treatment: "accept"
---

Context and Problem Statement

The local/ test harness offers an optional "layer 3 fidelity" tier backed by a
self-built oracle/database:19.3.0-ee image (local/docker-compose.oracle-19c.yml,
the oracle19c-up Make target). Building that image is high-friction and, on ARM64,
produces the wrong Oracle edition relative to the brokered product. Should we keep
this dependency or remove it and rely solely on the freely-pullable
gvenzl/oracle-free image for local development signal?

Decision Drivers

• The brokered product is Oracle 19c Standard Edition 2 (SE2), License Included —
  "License Included is SE2-only on RDS; Enterprise Edition is BYOL-only"
  (docs/oracle19c/design-notes.md, docs/oracle19c/licensing.md). The local EE
  image is therefore the wrong edition.
• No local SE2 image is achievable on ARM64. Oracle's own builder refuses it:
  ./buildContainerImage.sh -v 19.3.0 -s →
  "Currently only 19c enterprise edition and 26ai Free are supported on ARM64
  platform." The only ARM64 options are 19c EE and 26ai Free.
• The EE image can exercise EE-only features (Oracle-native TDE, Fine-Grained
  Auditing) that SE2 lacks and that the design explicitly compensates for (RDS
  storage-level AES-256/KMS encryption in place of TDE; unified auditing in place of
  FGA — docs/oracle19c/licensing.md). Validating those paths locally risks a
  misleading green for behavior that will not exist on the real SE2 RDS instance.
• Building EE requires authenticating to Oracle to download
  LINUX.ARM64_1919000_db_home.zip (~2.2 GB) or staging that file / image in a
  non-public store — operational and licensing friction for every developer.
• Authoritative STIG-conformance validation happens on a real brokered GovCloud RDS
  SE2 instance regardless (per the overlay repo and
  docs/oracle19c/validation-contract.md). The local harness is explicitly labeled
  "development signal only — not compliance evidence."
• gvenzl/oracle-free is freely pullable, native ARM64, and already the harness
  default (cg-oracle-free, FREEPDB1).

Considered Options

1. Keep the 19c EE image — Maintain the self-built EE fidelity tier alongside
   oracle-free.
2. Replace it with a local SE2 image — Match production edition locally.
3. Remove the EE dependency; keep gvenzl/oracle-free (26ai) as the sole local
   engine — Document the version-fidelity caveat; rely on real RDS SE2 for
   authoritative validation.

Decision Outcome

Chosen option: Option 3 — remove the EE dependency and keep gvenzl/oracle-free,
because Option 2 is impossible on ARM64 (the builder supports only EE and Free),
and Option 1's marginal benefit (correct 19c version string) is outweighed by its
cost (auth/2.2 GB/private-registry friction) and its risk of validating wrong-edition
hardening paths. Edition-accurate conformance is proven on the real RDS SE2 instance
either way.

Positive Consequences

• Removes a licensing- and bandwidth-encumbered build step; every developer can run
  layer 3 with a single free docker pull.
• Eliminates the wrong-edition "misleading green" risk (TDE/FGA paths that SE2 lacks).
• Simplifies local/ to a single Oracle engine (fewer compose files, Make targets,
  and README branches to maintain).

Negative Consequences

• Loss of 19c version fidelity locally. gvenzl/oracle-free is the 23ai/26ai
  engine, not 19c; 19c-specific defaults, deprecated parameters, or profile behavior
  will not be exercised locally. This gap is accepted because local layer 3 is
  development signal only.
• Anyone wanting a true 19c engine locally must build EE manually (still possible;
  just no longer wired into the harness).

Compliance Consequences

• No ATO-boundary impact: this is local developer tooling, not part of the
  authorization boundary, and produces no compliance evidence (CA-2 evidence still
  comes from the RDS SE2 run).
• CM-2 / documentation: remove the three local/ references (compose file,
  Makefile oracle19c-up/COMPOSE_ORACLE19C/down, README layer-3 build section)
  so the harness inventory has no dangling EE mentions.
• SA-11 / SA-15: the run-and-verify story is unchanged — unit + moto + local
  oracle-free remain; authoritative STIG validation remains on real RDS SE2.
• Confirm PR feat(oracle19c): STIG-hardened Oracle Database 19c brokered RDS support - DEV branch #537's docs/oracle19c/ do not promise a local 19c parity pass before
  that PR merges, so the documented validation strategy stays consistent.

Links

• local/docker-compose.oracle-19c.yml, local/Makefile, local/README.md — the
  references to be removed.
• docs/oracle19c/design-notes.md, docs/oracle19c/licensing.md,
  docs/oracle19c/limitations.md — SE2 edition rationale and TDE/FGA compensation.
• docs/oracle19c/validation-contract.md — authoritative RDS-based validation.
• cloud-gov/aws-broker PR feat(oracle19c): STIG-hardened Oracle Database 19c brokered RDS support - DEV branch #537 (feat/oracle-19c-stig-brokered-rds) — parent Oracle
  effort; PR chore(local): add local Oracle dev/test harness #545 (chore/local-dev-harness) — the harness this ADR modifies.

[pburkholder]

I don't think the above comment really needs to be documented beyond what's in the local/README.md file.