-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Link to known attestations in repository #98
Comments
I'd be happy to file a PR adding a markdown file to the repo with these links in. |
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? |
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 The problem is, I think, that the digest definition isn't valid JSON as defined in json.org.
A JSON object should consist of static keys with values. This is also the case in 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. |
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. 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 |
You are right, I have created #269 |
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:
invocation.parameters
,invocation.environment
andbuildConfig
The text was updated successfully, but these errors were encountered: