Link to known attestations in repository #98

Open joshuagl opened 2 years ago

In today's in-toto community call while discussing open ITE's we discussed it being useful for both adopters and maintainers to have a collection of different in-toto attestations that exist in the wild.

Some examples I know of:

SLSA provenance (v0.2) – designed to describe how a subject artefact was produced, with several opaque fields to be defined by buildType: invocation.parameters, invocation.environment and buildConfig
SLSA Verification Summary Attestation (VSA) – summarise verification of a number of SLSA attestations without a (trusting) user having to check, or even have access to, each attestation
Cosign generic attestation – attest arbitrary data with a timestamp
Cosign vulnerability attestation – designed for container vulnerability scans, has opaque type for scan results

I'd be happy to file a PR adding a markdown file to the repo with these links in.

SLSA provenance (v0.2) – designed to describe how a subject artefact was produced, with several opaque fields to be defined by buildType: invocation.parameters, invocation.environment and buildConfig

Tekton SLSA provenance

GitLab SLSA provenance

Amber SLSA provenance

Need to review these and see how much they differ from the SLSA provenance format. Is it just the opaque fields, or are there other differences and/or extensions?

I was thinking it would be nice to have some tool to validate SLSA provenance against the spec. I've certainly run into cases where people claimed to be doing it but some fields were incorrect.

Are there any current best practices on validating JSON schemas?

json-schema.org seems to be the thing. We could define schemas using it and then power some or all of the validation using the associated tooling. Not sure how folks feel about that?

json-schema.org seems to be the thing. We could define schemas using it and then power some or all of the validation using the associated tooling. Not sure how folks feel about that?

I support this! I remember looking into json schema some years ago, when we started developing the in-toto reference implementation. Back then spec/tooling did not seem mature enough. Looks like this has changed.

I agree it would be great to be able to validate provenance against the spec. I'm not familiar with json-schema.org but it does seem to be popular among colleagues faced with similar problems.

Here's an example of what the json-schema for in-toto statements would look like:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://in-toto.io/Statement/v0.1.schema.json",
  "properties": {
    "_type": {
      "description": "TODO",
      "type": "string",
      "const": "https://in-toto.io/Statement/v0.1"
    },
    "subject": {
      "description": "TODO",
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": {
            "type": "string"
          },
          "digest": {
            "type": "object",
            "minProperties": 1
          }
        },
        "required": [
          "name",
          "digest"
        ]
      }
    },
    "predicateType": {
      "description": "TODO",
      "type": "string",
      "format": "uri"
    },
    "predicate": {
      "description": "TODO",
      "type": "object"
    }
  },
  "required": [
    "_type",
    "subject",
    "predicateType"
  ]
}

We'd probably want to also define individual schemas for each of the 'official' predicate types.

I'd assume people would want us to have some sort of command line validator. I'd normally default to golang but it doesn't look like the latest golang implementations support the 2020-12 draft. Perhaps we should pick a python one?

Thoughts?

We from Argos Notary would very much like to migrate from an in-toto like structure to using attestations.

I have time and, I think, expertise, so I want to create the schemas and the verification process. But I think the proposed schema isn't detailed enough. Especially the digest.

The problem is, I think, that the digest definition isn't valid JSON as defined in json.org.

{
  "<ALGORITHM_1>": "<HEX/BASE64 VALUE>",
  "<ALGORITHM_2>": "<HEX/BASE64 VALUE>",
  ... 
}

A JSON object should consist of static keys with values.

This is also the case in ResourceDescriptor.

In our project we are using openapi, Jackson, Spring Data, MongoDB, Javascript, React, Axis. All these expect valid JSON and you get in a lot of trouble if it isn't.

A JSON object should consist of static keys with values.

Can you provide a reference to where that restriction is indicated? I don't see it at json.org or in this copy of the standard.

Also perhaps this should be tracked as a separate issue?

Hi Tom,

It is all a bit implicit but if you look under "6 objects" in your reference in the text: " name/value pairs. A name is a string. A single colon token follows each name, separating the name from the value.".

At least I interpret it as, a name is static and the value variable.

As an example we are searching on the hash in the database and it isn't possible to define an index in mongodb as the digest is now defined.

You are right, I have created #269

in-toto / attestation

Link to known attestations in repository #98