# Security Policy — mgf-vm-interchange

## Reporting a vulnerability

**Do not** file a public issue or open a PR for a suspected vulnerability. Instead:

- **Email**: `bassam@magogi.org` with the subject prefix `[mgf-vm-interchange security]`.
- Include: a description of the issue, the affected component, a proof-of-concept where possible, and the impact you observed.
- Acknowledgement target: within **5 business days**. Fix or documented mitigation target: within **30 days** for confirmed, exploitable issues. Coordinated disclosure timelines are negotiated case-by-case.

For non-security friction (a design call you'd push back on, a missing primitive, an awkward contract), file in [`FEEDBACK.md`](FEEDBACK.md) — the public, designed-for-friction channel.

## Scope

`mgf-vm-interchange` is a **pure-Python library** — OVF/OVA interchange (import +
export), state machine, typed contracts, fakes. No native deps, no privileged
operations, no sockets / network connections.

**It DOES parse untrusted input + touch the filesystem** — that is its job. OVF
descriptors (XML) and OVA archives (tar) originate *outside* the trust boundary
(operator-supplied / imported images), so the parsing surface is the primary
attack surface and is hardened accordingly:

- **OVF XML** — parsed via `defusedxml` (`_xml.py`), which refuses external
  entities, entity-expansion ("billion laughs"), and DTD/SYSTEM retrieval; a
  `max_bytes` cap is applied **before** parse (XML-bomb defense). Malformed input
  surfaces as a typed `ParseError`, never a hang or RCE.
- **OVA archives** — tar read/write (`exporter.py` / importer); extraction MUST
  guard against path-traversal ("tar-slip") and resource-exhaustion members.
- **Filesystem** — `parse_ovf` / `parse_xml_file` read from consumer-supplied
  disk paths; the library does not fetch over the network.

Threats in scope: XXE / entity expansion (mitigated — defusedxml), XML/zip bombs
(mitigated — `max_bytes`), tar-slip path traversal on extract, malformed-input
crashes. Out of scope: privilege, sockets, hardware. The hardware-touching
surface lives in the adapter libraries (`mgf-vm-libvirt`, `mgf-vm-firecracker`)
and the privileged daemons (`vm-vmanager-agent`), each with its own `SECURITY.md`.

## Threat model — read these first

Architectural threat-model context lives in the central docs repo:

- `vm-vmanager-docs/ARCHITECTURE.md` (boundaries, privilege model)
- `vm-vmanager-docs/DECISIONS.md` (security-related ADRs: D-D3 identity, D-D4 multi-tenancy, D-G3 error taxonomy, D-G4 log redaction)

## Standards alignment

This library follows the `mgf-common` SC-* rules. The per-rule status is tracked in `docs/inprogress/MGF_STANDARDS_CONFORMANCE.md`.
