Security & Trust
Last updated June 30, 2026
A registry is only as good as the trust you can place in it. Here's how kpkg protects who can publish, the integrity of what you download, and the platform itself.
Who can publish
Publishing is namespace-isolated. An account can only upload under a namespace it has verified ownership of — io.github.<login> via GitHub, or a custom domain via a DNS TXT challenge. A publish token outside its verified namespace is rejected.
- Publish tokens authenticate over HTTPS; only a hashed form of the secret is ever stored, compared in constant time.
- Released versions are immutable — a published release can never be overwritten, only superseded.
- Deletion of artifacts is disabled, so a dependency can't vanish out from under you.
Integrity & provenance
kpkg never rewrites artifact bytes. Checksums and GPG signatures (.asc) are produced by the publisher's own build and stored verbatim, exactly as Maven Central does. A locally-published release artifact is withheld unless its GPG signature is present, so what you resolve is what the author signed.
Platform hardening
The site and registry ship with a defense-in-depth posture:
- Strict Content-Security-Policy, HSTS, and clickjacking protection on every response.
- README images proxied server-side with SSRF guards and size limits — no IP leak to third-party hosts, strict image policy preserved.
- Path validation and rate limiting on the registry to prevent abuse and amplification.
- Cloudflare's network absorbs volumetric DDoS automatically at the edge.
Reporting a vulnerability
Found something? Please report it privately first — reach @android_poet on X rather than opening a public issue, and give us a chance to fix it before disclosure. Responsible reports are genuinely appreciated.