atrib is cryptographic infrastructure.
Do NOT open a public GitHub issue for security vulnerabilities.
Instead, email security@atrib.dev with:
- Description of the vulnerability
- Steps to reproduce
- Affected versions/components
- Potential impact
- Ed25519 signature bypass or forgery
- Merkle proof forgery or inclusion proof manipulation
- JCS canonicalization collision that produces valid signatures for different records
- Timing attacks on signing or verification
- Key material exposure through API responses or logs
- Input validation bypass that leads to data corruption
- Supply chain attacks on published packages
- Denial of service on
@atrib/log-dev(it's a dev-only fixture, not production infrastructure) - Issues in example code under
packages/integration/examples/ - Feature requests or general bugs (use GitHub Issues for these)
- Acknowledgment: Within 48 hours
- Initial assessment: Within 7 days
- Patch release: Within 90 days for confirmed vulnerabilities
| Version | Supported |
|---|---|
| 0.1.x | Yes |
The previous extract-zip and adm-zip alerts are resolved in the dependency
graph. The private browser-use integration now reads DOCX entries in memory
with adm-zip@0.6.1; it no longer depends on extract-zip or writes archive
entries to disk. The scheduled security workflow runs
pnpm security:archive-dependencies, which fails if either vulnerable shape is
reintroduced. A future browser-use upgrade must preserve this boundary and pass
the OSV scan before it lands.
We credit security researchers in release notes (unless you prefer anonymity). Let us know your preference when reporting.
atrib uses exclusively audited libraries implementing published standards:
| Component | Standard | Library |
|---|---|---|
| Signing | Ed25519 (RFC 8032) | @noble/ed25519 (audited) |
| Hashing | SHA-256 | @noble/hashes (audited) |
| Canonicalization | JCS (RFC 8785) | canonicalize |
| Merkle tree | RFC 6962 (Certificate Transparency) | In-house, tested against Wycheproof vectors |
No custom cryptography.
The protocol is about provable signed records; the project's own release artifacts are signed end-to-end so consumers can verify what they're running matches what was committed.
| Surface | Mechanism | How to verify |
|---|---|---|
| Commits | SSH commit signing (Ed25519 key uploaded to GitHub) | git log --pretty='%h %G? %GS %s' locally; "Verified" badge on github.com per GitHub's commit-signature-verification |
npm packages (@atrib/*) |
npm publish --provenance (Sigstore + SLSA L3) |
npm view @atrib/<pkg> dist.attestations; visible as "verified" badges on npmjs.com; transparency-log entries in Rekor |
| WASM artifact (directory) | --remap-path-prefix (build-time) |
strings packages/directory/wasm/atrib_directory_bridge_bg.wasm should contain no /Users/ or /home/ paths |
| CI workflows | GitHub Actions OIDC | Security-scan results visible at github.com/creatornader/atrib/actions; SARIF uploaded to GHAS Code Scanning when public |
The release-artifact surface (npm packages) carries Sigstore-anchored provenance attestations recorded in the public Rekor transparency log. Anyone can independently verify that a published @atrib/* package was built from the claimed source at the claimed time, without trusting any central issuer. This is the same trust model atrib provides for agent actions: cryptographic primitives plus a public log, no central authority required. Commits use industry-standard SSH signing for the same identity-binding property at the level GitHub's UI recognizes; npm provenance is the transparency-log surface downstream consumers rely on, because it affects what those consumers run.