Remove builder

README.md

@@ -22,24 +22,25 @@ The life cycle of an endorsement statement has three phases as shown in the diag
 ### The pre-release phase
 
 In this phase, a trusted builder, for instance
-[the generic slsa-generator GitHub workflow](https://github.com/slsa-framework/slsa-github-generator/blob/de4491844e9be4184f786666af40f5b1b8e7ddc0/internal/builders/generic/README.md),
-generates a binary and a corresponding SLSA provenance statement. The trusted builder also signs the
-generated SLSA provenance statement. A provenance statement is another type of metadata about a
-binary that describes how and from which sources the binary was generated. Both the SLSA provenance
-statements, and our endorsement statements are customizations of the in-toto statements standard,
-and refer to one or more binaries as the subject of the statement. A binary can be uniquely
-identified by its cryptographic hash. The cryptographic hash function often used for identifying a
-binary is SHA256. For details about the format of the provenance statement please refer to
-[the SLSA provenance documentation](https://slsa.dev/provenance/v0.2).
+[the container-based SLSA3 builder workflow](https://github.com/slsa-framework/slsa-github-generator/blob/f14d71f7a0f58a45b6105c0b6d97c414328ceda0/internal/builders/docker/README.md),
+from the SLSA Framework, builds a binary and generates a SLSA v1.0 provenance statement for it. The
+trusted builder also signs the generated provenance statement. A provenance statement is another
+type of metadata about a binary that describes how and from which sources the binary was generated.
+Both the SLSA provenance statements, and our endorsement statements are customizations of the
+in-toto statements standard, and refer to one or more binaries as the subject of the statement. A
+binary can be uniquely identified by its cryptographic digest. The cryptographic hash function often
+used for identifying a binary is SHA256. For details about the format of the provenance statement
+please refer to [the SLSA v1.0 provenance documentation](https://slsa.dev/provenance/v1).
 
 We need provenance statements to be signed and published in a transparency log. This log, in case of
-the generic slsa-generator GitHub workflow, is an instance of Rekor hosted by sigstore. The binary
-is often uploaded to a storage server for future use. This can be content-addressable storage such
-as [ent](https://github.com/google/ent).
-
-To support the pre-release phase we provide the
-[cmd/builder](/cmd/README.md#building-binaries-using-the-cmdbuilder-tool) tool and a
-[guide on how to get started on your repo](https://github.com/project-oak/hello-transparent-release).
+the container-based SLSA3 builder workflow, is an instance of Rekor hosted by Sigstore
+(https://rekor.sigstore.dev). The binary is often uploaded to a storage server for future use. This
+can be a content-addressable storage such as [ent](https://github.com/google/ent).
+
+For a detailed description of how to use the
+[the container-based SLSA3 builder workflow](https://github.com/slsa-framework/slsa-github-generator/blob/f14d71f7a0f58a45b6105c0b6d97c414328ceda0/internal/builders/docker/README.md)
+in your project see the
+[hello-transparent-release tutorial](https://github.com/project-oak/hello-transparent-release).
 
 ### The release phase
 

cmd/verifier/README.md

@@ -0,0 +1,34 @@
+# Verifying provenances
+
+The [`verifier`](/internal/verifier/) package provides functionality for verifying an input
+provenance file. The provenance file should follow the
+[Amber provenance](./../pkg/amber/schema/v1/provenance.json) format and provide a list of materials
+(including the source code and the build toolchain), and steps for building a binary from the listed
+materials. The verification logic uses the provenance file to build a binary, and checks that the
+binary has a SHA256 hash equal to the expected digest given in the provenance file.
+
+Note that the Amber provenance format will soon be deprecated (see
+[issue #224](https://github.com/project-oak/transparent-release/issues/224)), and replaced with
+[SLSA v1.0 format](https://slsa.dev/provenance/v1).
+
+To verify a SLSA provenance of the Amber build type run:
+
+```console
+$ go run cmd/verifier/main.go -provenance_path schema/provenance/v1/example.json
+```
+
+This fetches the sources from the Git repository specified in the SLSA statement file, re-runs the
+build, and verifies that it yields the expected hash.
+
+Check the [`development guidelines`](./../docs/development-guidelines.md) for a quick start to
+[`verifying provenances`](./../docs/development-guidelines.md#verifying-provenances).
+
+To use a local repository you can specify `-git_root_dir`. In this case, the binary will be built
+from the repo, only if the latest commit matches the one specified in the config file fail with an
+error otherwise.
+
+```console
+$ go run cmd/verifier/main.go \
+  -provenance_path schema/provenance/v1/example.json \
+  -git_root_dir <path-to-git-repo-root>
+```