ShardLift is a pre-alpha correctness lab, not a security-hardened production system. Security reports are still useful, especially when a flaw can escape the documented local trust boundary, select an invalid checkpoint, forge evidence, act on the wrong process, traverse an authority path, or exhaust resources before a declared bound is enforced.
| Version or branch | Status |
|---|---|
main / 0.1.0.dev0 |
Development only; reports are accepted and fixes are best-effort |
| Stable releases | None currently published or supported |
There is no response-time, embargo, compatibility, or backport SLA. Until a stable release policy exists, fixes may change development formats or APIs when that is necessary to fail closed.
Use GitHub's private Security Advisory flow for this repository:
Report a vulnerability through GitHub Security Advisories
If the direct form is unavailable, use the repository's Security tab to start a private advisory. Do not open a public issue, discussion, or pull request containing an unpatched vulnerability. If no private channel is exposed, a public issue may ask the maintainer to enable private reporting, but it should contain no technical details.
Include, when available:
- the affected revision, version, Python version, kernel, architecture, and filesystem;
- the smallest safe reproduction or malformed input;
- the violated invariant and observed versus expected behavior;
- whether the issue requires a malicious same-UID process, a hostile checkpoint tree, external filesystem mutation, or only ordinary public inputs;
- impact on process targeting, checkpoint selection, evidence integrity, confidentiality, availability, or resource bounds; and
- any temporary mitigation that does not destroy forensic evidence.
Do not include real credentials, private datasets, proprietary checkpoints, or third-party personal data. Please avoid destructive testing against systems you do not own.
The v0.1 evidence contract assumes a trusted local execution environment:
- the invoking user, parent supervisor, coordinator, and workers are trusted;
- the Linux kernel,
/proc, Python runtime, PyTorch runtime, and local filesystem behave according to their documented interfaces; - the physical source checkout and expected Git revision are supplied by the caller;
- rollback anchors and expected checkpoint identities come from outside the checkpoint tree;
- the dataset identity, configuration, workload, and schema digests are trusted inputs; and
- cooperating processes run under the expected user identity in private directories.
Within that boundary, ShardLift attempts to:
- target direct children through retained process authority and prove terminal cleanup;
- reject symlink traversal, unsafe path spelling, unexpected ownership or modes, and cross-filesystem checkpoint installation where checked;
- validate canonical schemas, lengths, digests, sequence numbers, ranks, sessions, and membership epochs before accepting state;
- enforce byte, item, recursion, descriptor, timeout, and cleanup-evidence bounds;
- make immutable commit records authoritative and treat
refs/LATESTas a rebuildable hint; - detect incomplete, corrupt, swapped, duplicated, truncated, or trailing checkpoint and evidence bytes; and
- bind a completed demo audit to its adjacent evaluation and recovery records.
These are correctness defenses inside a trusted-host experiment. They have not been presented as a general sandbox or adversarial multi-tenant isolation mechanism.
ShardLift v0.1 does not claim protection against:
- a malicious root user, kernel, hypervisor, Python runtime, PyTorch build, or dependency;
- a hostile same-UID process able to inspect or mutate the user's files or processes;
- Byzantine workers, a malicious coordinator, arbitrary code execution inside a worker, or untrusted plugins;
- malicious replacement or rollback authenticated only by SHA-256 without an external trust anchor or signature;
- power loss, controller-cache loss, storage firmware faults, or durability beyond the documented local ext4 process-crash experiment;
- NFS, network filesystems, object stores, multi-host protocols, network attackers, or remote service exposure;
- denial of service outside declared parser and session bounds, including disk exhaustion, process-table exhaustion, or an administrator defeating resource limits;
- confidentiality of training data, model state, audit metadata, command-line arguments, process identifiers, paths, platform details, or package inventory; or
- production hardening, formal verification, penetration-test coverage, or compliance with a security standard.
SHA-256 is used for identity binding and corruption detection, not authentication. A real
SIGKILL is used for fail-stop process testing, not for power-cut testing. Offline W4 -> W3
resharding does not establish safe live membership changes.
Run directories and audit bundles can contain model and optimizer state plus detailed provenance. Keep them in owned private directories, inspect them before sharing, and remove them according to your own retention policy only after they are no longer needed for failure analysis.
The public demo may download pinned Fashion-MNIST resources and installation instructions may download pinned Python wheels. Hash checks detect byte mismatches but do not replace transport security, package-index trust, source review, or an externally authenticated release process. Do not put confidential data in the Fashion-MNIST cache or adapt the public demo to secret data without designing a separate confidentiality and retention model.