ASPL is a trust and supply-chain protocol, so its own security posture matters.
Please report security issues privately to hello@tilelli.tech rather than opening a public issue. Include:
- a description of the issue and its impact,
- steps to reproduce (a failing
tests/test_adversarial.py-style case is ideal), - the affected version / commit.
We aim to acknowledge reports promptly and will coordinate disclosure.
The reference implementation is alpha. Known, documented limitations (these are not vulnerabilities — they are stated boundaries):
- Proof-of-work is a speed-bump, not a strong sybil barrier. Difficulty is
configurable (
ASPL_POW_DIFFICULTY); a GPU/native solver is far faster than the pure-Python reference solver. - The environment probe is not a security sandbox. The optional smoke probe runs under resource limits but must not be treated as isolation.
- Publish-time scanning is best-effort. It normalises unicode/homoglyphs, decodes base64/hex, and does AST analysis, but content scanners are fundamentally heuristic and can be evaded.
- Trust is advisory metadata. Clients decide their own thresholds; a trust score is not a safety guarantee.
- forged/missing API keys, forged delivery signatures, tampered delivery content,
transaction replay, cross-agent transaction theft — all rejected
(
tests/test_adversarial.py); - revocation cannot be bypassed by pre-accepting (delivery re-checks revocation);
- the trust model resists self-confirmation / single-identity pumping (distinct-confirmer counting, self-dealing excluded);
- the transparency log supports inclusion and consistency proofs so log rewrites are detectable.