What is proposed, before it binds.

Draft features (4)

• F11Executing contributed codesource
• J1Container-engine abstractionsource
• J2Running under Podmansource
• J3Running natively, without containerssource

Draft requirements (52)

• F11-R1This feature MUST NOT be implemented while F3-R6 stands, and retiring F3-R6 MUST be a superseding decision record that states what changed, never an edit to the requirement in place.source
• F11-R2A proposal MUST answer both objections already recorded — that a sandbox confines computation while the risk is I/O, and that an opaque artefact forecloses the readable review F3-R10 asks for — rather than asserting that the sandbox is strong.source
• F11-R3A proposal MUST name the cases recipes and named adapters genuinely cannot express, with an example of each, and MUST NOT rest on the possibility that such cases exist.source
• F11-R4Contributed code, if it is ever executed, MUST NOT hold lemonfiber's own authority on the machine: the credential store, the container runtime's socket and the data root MUST be unreachable from it by construction rather than by policy.source
• F11-R5What contributed code may reach MUST be stated in advance and checkable without running it, and a reach beyond what was stated MUST be refused rather than logged.source
• F11-R6An operator MUST be able to tell from an installed plugin whether any part of it executes in lemonfiber's process, without reading its source.source
• F11-R7Where the confinement a proposal depends on cannot be enforced on a supported platform, the code MUST be refused there and reported as refused — never run unconfined, and never reported as run.source
• F11-R8Contributed code that cannot be loaded or run MUST be reported as unrun and MUST NOT be reported as passed, satisfied, or by being omitted.source
• F11-R9Nothing this feature introduces may widen what a plugin's container may reach (F3-R24), and a proposal MUST say so explicitly rather than leaving it inferred.source
• F11-R10Contributed code MUST NOT be able to register itself over a bundled check, remedy or command; F4-R17 holds whatever the mechanism.source
• J1-R1The tool MUST detect the container engines installed on the host and classify each as usable, present-but-unusable, or absent.source
• J1-R2Engine usability MUST be established from a successful round-trip command, not from the mere presence of a socket or binary.source
• J1-R3Bring-up, teardown, inspection, in-container execution, and health reads MUST be expressed once and mapped onto the selected engine.source
• J1-R4The VPN egress proof, the hardlink inode proof, and per-service health checks MUST run identically across every supported engine, with no engine-specific variation in the checks themselves.source
• J1-R5The egress and hardlink proofs MUST pass on each supported engine before that engine is reported as verified.source
• J1-R6Proofs MUST observe the running result — namespaces, addresses, inodes — and MUST NOT be satisfied by reading the compose file or trusting the engine's own report.source
• J1-R7A capability the selected engine cannot express MUST be reported explicitly, and MUST NOT be silently skipped.source
• J1-R8A proof that could not run MUST be distinguished from a proof that ran and passed.source
• J1-R9When more than one engine is usable, the selection MUST be stated and MUST be overridable by the operator.source
• J1-R10When no usable engine is present, the tool MUST say so and MUST NOT silently degrade.source
• J1-R11A divergence in proof results between two engines MUST be surfaced rather than averaged or hidden.source
• J1-R12Engine detection, selection, and running the verification suite against a named engine MUST each be reachable non-interactively.source
• J1-R13Adding support for a further engine MUST NOT require changing the verification suite.source
• J1-R14The operator MUST NOT need to know engine-specific commands to drive the stack through the common interface.source
• J2-R1The tool MUST be able to run the full stack on Podman with no dependency on Docker.source
• J2-R2The tool MUST offer both a Docker-compatible mode and a native system-unit mode, and let the operator choose.source
• J2-R3The native-unit mode MUST reproduce the download client joining the VPN container's network namespace.source
• J2-R4The native-unit mode MUST gate startup ordering on a dependency being HEALTHY, not merely started.source
• J2-R5The native-unit mode MUST be boot-persistent and MUST be offered only on Linux.source
• J2-R6The VPN egress proof and the hardlink inode proof MUST both pass under Podman in each mode before the stack is reported as running correctly.source
• J2-R7The shared network namespace MUST be verified at runtime from inside the running client, and MUST NOT be inferred from the unit or compose file.source
• J2-R8The tunnel MUST be re-proven on every start, not assumed from a previously working configuration.source
• J2-R9Where rootless operation cannot grant the tunnel device or network capability, the tool MUST lead with a rootful or a documented tested rootless recipe rather than a silent partial start.source
• J2-R10Where user-namespace UID shifting would break hardlinks, the tool MUST align UIDs and MUST confirm linking with a filesystem inode check.source
• J2-R11A namespace or hardlink check that could not be confirmed MUST be reported as unproven, never as passed.source
• J2-R12Requesting native-unit mode on a non-Linux host MUST be refused with an explanation, offering the compatibility mode instead.source
• J2-R13Mode selection, unit generation, and running the egress and hardlink proofs under Podman MUST each be reachable non-interactively.source
• J2-R14A tunnel drop MUST leave the download client with no route out, verified by asserting no egress while the tunnel is down.source
• J3-R1The tool MUST be able to run the services as native host services under the init system with no container engine in the path, on Linux.source
• J3-R2VPN isolation MUST be rebuilt as a dedicated network namespace holding the VPN interface, with the download client bound into that namespace.source
• J3-R3A kill rule inside the namespace MUST ensure that if the tunnel drops there is no route out.source
• J3-R4The egress-IP proof MUST run inside the dedicated namespace, comparing the address seen there against the host's, and MUST assert they differ.source
• J3-R5The killswitch MUST be proven by bringing the tunnel interface down and asserting there is then no egress at all.source
• J3-R6Hardlinking MUST be proven by creating a file, linking it, and comparing inodes on the real data root.source
• J3-R7An egress address inside the namespace equal to the host's MUST be treated as a leak and MUST halt the stack.source
• J3-R8A namespace or client binding that cannot be confirmed MUST be reported as unproven, never as isolated.source
• J3-R9The tool MUST state that the native path forfeits the VPN-provider abstraction the container gave, making provider configuration and reconnection the operator's responsibility.source
• J3-R10The tool MUST state that the native path is the highest-effort option.source
• J3-R11The native path MUST be refused on hosts without network namespaces, with the reason given, and MUST NOT be offered on macOS.source
• J3-R12Standing up the namespace, binding the client, installing the kill rule, and running the egress and hardlink proofs MUST each be reachable non-interactively.source
• J3-R13Isolation, client binding, and the kill rule MUST reassert after reboot, with egress re-proven rather than assumed.source
• J3-R14Egress MUST be re-proven after any change to the VPN provider configuration.source

Open RFC issues (0)

None.