Skip to content

Latest commit

 

History

History
96 lines (67 loc) · 3.74 KB

README.md

File metadata and controls

96 lines (67 loc) · 3.74 KB
Raw

Rekor

Rekór - Greek for “Record”

Rekor's goals are to provide an immutable tamper resistant ledger of metadata generated within a software projects supply chain. Rekor will enable software maintainers and build systems to record signed metadata to an immutable record. Other parties can then query said metadata to enable them to make informed decisions on trust and non-repudiation of an object's lifecycle. For more details visit the sigstore website

The Rekor project provides a restful API based server for validation and a transparency log for storage. A CLI application is available to make and verify entries, query the transparency log for inclusion proof, integrity verification of the transparency log or retrieval of entries by either public key or artifact.

Rekor fulfils the signature transparency role of sigstore's software signing infrastructure. However, Rekor can be run on its own and is designed to be extensible to working with different manifest schemas and PKI tooling.

Public Instance

A public instance of rekor can be found at rekor.sigstore.dev

IMPORTANT: This instance is currently operated on a best-effort basis. We will take the log down and reset it with zero notice. We will improve the stability and publish SLOs over time.

This instance is maintained by the Rekor community. Interested in helping operate and maintain our production CA system and Transparency Logs? Please reach out via the mailing list.

If you have production use-cases in mind, again - please reach out over email via the mailing list. We are interested in helping on board you!

Installation

Please see the installation page for details on how to install the rekor CLI and set up / run the rekor server

Usage

For examples of uploading signatures for all the supported types to rekor, see the types documentation.

Auditing the Instance

We run a job to publish the latest Signed Tree Hashes on GCS. They are served publicly, and can be found with:

gsutil ls gs://rekor-sth/
gs://rekor-sth/sth-1173.json

The format is currently:

$ gsutil cat gs://rekor-sth/sth-1173.json | jq .
{
  "SignedLogRoot": {
    "key_hint": "Ni+Oy6cvQyY=",
    "log_root": "AAEAAAAAAAAElSB3sp4yw0NFEWsTB6RT5mjr6GCKxVQ8Tlym+P3uKTQwuxZquNPzzd3mAAAAAAAACIUAAA==",
    "log_root_signature": "MEUCIQCb8QHWym7jBvBMFk8ir1ZTqT83zpjE0c90vi7VrTG70wIgBwQmaQ96Od62ODZkdT6r1eVsl4r14tYR1MwQbkNv8ZM="
  },
  "VerifiedLogRoot": {
    "TreeSize": 1173,
    "RootHash": "d7KeMsNDRRFrEwekU+Zo6+hgisVUPE5cpvj97ik0MLs=",
    "TimestampNanos": 1615306636833709600,
    "Revision": 2181,
    "Metadata": ""
  }
}

We store them in both raw (unverified) and decoded (verified) formats. You can verify the signatures against Rekor's public key.

These entries contain the tree length, tree root hash as well as the timestamp. The (signed) timestamp and index of a (signed) tree hash may be used as an attestation that any entries in the log prior to this index were witnessed by Rekor before this time.

Extensibility

Custom schemas / manifests (rekor type)

Rekor allows customized manifests (which term them as types), type customization is outlined here.

API

If you're interesting in integration with Rekor, we have an OpenAPI swagger editor

Security

Should you discover any security issues, please refer to sigstores security process

Contributions

We welcome contributions from anyone and are especially interested to hear from users of Rekor.