What does Sigstore's Rekor transparency log actually record when an artifact is signed?
answer
- append-only and publicly readable
- records the fact, not the file
- digest, signature, certificate
- Merkle tree plus signed entry timestamp
- a record, not an endorsement
basics
~20 sRekor appends an entry holding the artifact's digest, the signature over it, and the signing certificate or public key. It never stores the artifact itself — only a timestamped, publicly readable record that this signature existed.
solid answer
~40 sRekor is Sigstore's append-only transparency log. When `cosign` signs something, it uploads an entry containing the digest of what was signed, the signature, and the certificate Fulcio issued for the signer's identity (or a bare public key, for key-based signing). Rekor appends that entry to a Merkle tree and hands back a signed entry timestamp — the log's own signature saying it accepted the entry at that moment. The artifact's contents never leave your machine; only the hash does. Just as important is what an entry does not mean: anyone can sign anything and log it, so presence in Rekor is evidence that a signature was made, not an endorsement that the artifact is safe.
go deeper
Be ready to say in one breath what goes into an entry — digest, signature, signing certificate — and what does not: the artifact itself. Knowing that the log is append-only and public is enough at this level.
Expect to explain the Merkle tree, the published checkpoint, and the signed entry timestamp the log returns on upload, and to describe how an inclusion proof is checked against a root hash.
Show that you treat the log as a detective control in a real pipeline: what you would search it for, what you would carry alongside artifacts so verification works offline, and why permanence changes what you are willing to publish.
Own the position that transparency is only worth what the watching is worth. Be able to argue when a public log earns its privacy cost for your organisation and what obligations you take on if you log nothing at all.
## What Rekor is Rekor is the transparency log component of the Sigstore project. It is an append-only, cryptographically verifiable log: entries can be added, never edited or removed, and every entry can be proven to be part of the log by a small proof rather than by trusting the operator's word. The public instance is run as a community good and is world-readable by anyone, with no account required to search it. The reason a signing system needs a log at all is that a signature on its own answers only one question — *who vouches for this?* — and answers it only while the verifier can still evaluate the signer's key or certificate. A log adds two things a signature cannot supply on its own: **time** (a trustworthy record of *when* the signature was made) and **discoverability** (anyone, including the claimed signer, can go looking for signatures made under a given identity). ## What an entry contains A Rekor entry is a small structured record. Its essential parts are: - **The digest of the signed thing** — a cryptographic hash of the artifact, blob, or attestation. This is what makes the entry findable: given a binary, you hash it and search the log for that hash. - **The signature** — the bytes produced by the signer over that digest. - **The verification material** — in keyless signing, the short-lived X.509 certificate Fulcio issued, which binds the ephemeral signing key to an OIDC identity (a person's email, or a workload such as a CI job). In key-based signing, the signer's public key instead. Rekor supports several entry *types* so that different payloads (a plain signed blob, or a signed attestation document) can be recorded with a schema the log understands. What is **not** in the entry is the artifact itself. Rekor is not a registry, a mirror, or a backup: it holds hashes and signatures, and it is deliberately small so that it can be replicated and audited cheaply. ## What the log gives back: the Merkle tree and the signed entry timestamp Entries are leaves of a Merkle tree — a hash tree in which each node is the hash of its children, so the single root hash commits to every entry beneath it. Rekor periodically publishes a signed *checkpoint* (a root hash plus a tree size, signed with the log's key). Two proofs fall out of that structure: - An **inclusion proof** is the short list of sibling hashes that lets you recompute the root from your entry. If the recomputed root matches a published checkpoint, your entry is provably in that log at that size. - A **consistency proof** shows that an earlier checkpoint is a prefix of a later one — that is, that the log only appended and never rewrote history. On upload, Rekor also returns a **signed entry timestamp (SET)**: the log's signature over the entry body together with the time it was integrated. That is the log asserting *I accepted this entry at this time*, and it is the piece that makes verification possible long after the signer's certificate has expired. ## What presence in the log does not mean This is the part interviewers probe, because it is where candidates over-claim. A Rekor entry means: *someone holding this identity produced this signature over this digest, and the log saw it at this time.* It does not mean the artifact was reviewed, scanned, built from the source you expect, or is free of vulnerabilities. An attacker who obtains a valid identity can sign malware and log it, and the log will faithfully record that too — which is the point. The log is a **detective** control, not a preventive one: it makes forged signatures discoverable rather than impossible. It also does not decide *whose* signature you should accept. Verification policy lives with the consumer: you check that the identity in the certificate is the one you expect (a specific maintainer, or a specific build workflow of a specific repository) and that it was issued by the OIDC issuer you expect. Verifying that a signature is merely *valid* — without pinning the expected identity — accepts a signature from anyone in the world. ## Practical consequences Because the log is public and permanent, everything you put in it is published forever: identities, digests, and timing. Because it is append-only, a mistaken upload cannot be withdrawn — the remedy is to publish a later, corrected statement, not to delete. And because entries are tiny, a verifier can carry the entry, certificate and inclusion proof alongside the artifact (`cosign` calls this a bundle) and verify without contacting the log at all.
- Does finding an artifact's digest in Rekor mean it is safe to run?No. It means someone signed that digest under some identity at some time. Anyone can sign anything and log it, so the entry proves authorship and timing, not quality or safety. Your policy still has to check that the identity in the certificate is one you actually trust, and vulnerability and provenance questions are answered by entirely separate artifacts.
- Can you delete a Rekor entry you uploaded by mistake?No — the log is append-only, and that is exactly the property that makes its proofs meaningful. If deletion were possible, an attacker who compromised the log could erase evidence of a forged signature. The only remedy is to publish something new: a corrected release, a fresh signature, or an advisory that tells consumers which entries not to trust.
- Why does the log store a digest instead of the artifact?So the log stays small enough to be replicated, mirrored and independently audited, and so signing never uploads your content to a public service. A digest is sufficient: verification hashes the artifact locally and looks for that hash, and any change to the artifact produces a different hash and therefore no match.
Think of it as a notary's public register rather than a safe: the register records that a document was witnessed, by whom, and when — it does not hold the document, and it does not say the document is true.
saying these in an interview costs you the question
- Says Rekor stores a copy of the signed artifact
- Treats presence in the log as proof the artifact is safe
- Thinks entries can be edited or deleted by the uploader
- Confuses the log with the thing that performs verification
- Claims the log decides which signers to trust