in-toto

attestation

Rust2022–2026

in-toto / attestation

attestation

in-toto Attestation Framework

Security & Privacy

Explore on GitHub Read Hacker News discussions

5Distinct people

5Mentions

0Explicit recommenders

390GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

in-toto Attestation Framework

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year5 dated mentions

Observed mentions: 2022-09-20 09:01:40 UTC to 2026-01-04 09:32:30 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	2	2
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

5 sources

jcgl·Jan 4, 2026

This does seem wildly overcomplicated. Here is the attestation system they use: https://github.com/in-toto/attestation/blob/main/spec/README... Why not Just(TM) enforce a reproducible build process? That brings some of its own challenges, but would represent a real upgrade over building out some Swiss cheese like this.

In PyPI in 2025: A Year in Review

westurner·Jun 11, 2025

GitHub specifically doesn't have Python package index (PEP 503, PEP 740) support on their roadmap: https://github.com/github/roadmap/issues/94#issuecomment-158... GitLab has Python package registry support (503?): https://docs.gitlab.com/user/packages/pypi_repository/ Gitea has Python package registry support (503?): https://docs.gitea.com/usage/packages/pypi PyPI supports attestations for Python packages when built by Trusted Publishers: https://docs.pypi.org/attestations/ : > PyPI uses the in-toto Attestation Framework for the attestations it accepts. [ in-toto/attestation spec: https://github.com/in-toto/attestation/blob/main/spec/README... ] > Currently, PyPI allows the following attestation predicates: > SLSA Provenance, PyPI Publish Artifact Registry > Artifact Registry documentation > Guides > Manage Python packages: https://clou

Read the rest

d.google.com/artifact-registry/docs/python/manag... : > [Artifact Registry] private repositories use the canonical Python repository implementation, the simple repository API (PEP 503), and work with installation tools like pip. PEP 503 – Simple Repository API: https://peps.python.org/pep-0503/ PEP 740 – Index support for digital attestations: https://peps.python.org/pep-0740/

In Publish a Python Wheel to GCP Artifact Registry with Poetry

adityasaky·Oct 25, 2023

It's multi-pronged and I imagine adopters may use a subset of features. Broadly, I think folks are going to be interested in a) branch/tag/reference protection rules, b) file protection rules (monorepo or otherwise, though monorepos do pose a very apt usecase for gittuf), and c) general key management for those who primarily care about Git signing. For those who care about a and b, I think the work we want to do to support in-toto attestations [0] for SLSA's upcoming source track [1] could be very interesting as well. [0] https://github.com/in-toto/attestation [1] https://github.com/slsa-framework/slsa/issues/956

In Gittuf – a security layer for Git

sublimefire·Apr 19, 2023

FYI there is a push to standardize this stuff under the name of SCITT in IETF [1]. In this case (blog post) this is different as NPM is using in-toto attestation [5] (a description of a thing) and logs it in Google's provided append only log (transparency service). They are trying to make this thing being adopted through a freemium model at the moment. One issue here is that NIST are trying to push SBOMs [2] but NPM is not providing them as part of the provenance I think. Another thing is a push to use new types of signature envelopes like DSSE [3] instead of something like COSE [4] [1] https://datatracker.ietf.org/group/scitt/about/ [2] https://www.nist.gov/itl/executive-order-14028-improving-nat... [3] https://github.com/secure-systems-lab/dsse [4] https://www.rfc-editor.org/rfc/rfc8152 [5] https://github.com/in-toto/attestation

In NPM Provenance Public Beta

lrvick·Sep 20, 2022

I have. I actually worked a few desks down from dpc when he was creating it and we talked about it at length. I felt then and now that it has good goals but a very limiting implementation in that it does not pursue a portable spec and instead anchors a very opinionated format to git, and github, instead of cryptographic keys held in hardware controlled by reviewers. I want to see the same keys that sign git commits also sign reviews, for instance. I think for broad adoption a review system should ask essentially the same questions as crev, but store them in a format like in-toto including signatures by the reviewers created with a user choice of pgp smartcards, ssh keys, or webauthn devices. These reviews would be anchored to hashes of a particular state of a particular tree of code and not to any type of VCS or distribution system. Impor

Read the rest

tant code is distributed via perforce, mercurial, cvs, subversion, and tar files depending if we are talking about big corps, old codebases, or linux distro building blocks. A good OSS review system should be also be usable by teams in their internal proprietary codebases too if we wish to see wide adoption. Even for OSS we may wish to share some reviews as standalone objects privately while security embargos are in place, etc. Proofs should also be verified standalone easily from local cache, when github is down, when original repos vanish, etc. Something that meets these broader needs will make it easy for large orgs with very different internal setups to participate and play nice with other supply chain security tooling efforts by the OpenSSF using in-toto for Sigstore, Witness, etc. My experience and visibility into internal review tooling of multiple companies tells me many need something very different than crev, but crev proved to me many people have real interest in this problem which I really thank dpc for. The biggest blocker for starting this project is the human review spec settling in in-toto https://github.com/in-toto/attestation/issues/77 Some relevant discussion here too: https://gist.github.com/lrvick/d4b87c600cc074dfcd00a01ee6275...

In There is no “software supply chain”