Closed shibumi closed 1 year ago
While investigating https://github.com/in-toto/in-toto-golang/issues/124 I think I have found a bug in our specification.
The question is: What happens when the "command" section in the link file is empty? (Vice versa with "expected_command" for the layout file).
In our Golang implementation such case looks like this right now:
{ "signed": { "_type": "link", "name": "write-code", "materials": {}, "products": { "foo.py": { "sha256": "74dc3727c6e89308b39e4dfedf787e37841198b1fa165a27c013544a60502549" } }, "byproducts": {}, "command": [], "environment": {} }, "signatures": [ ] }
Our python implementation has the following link:
{ "signatures": [], "signed": { "_type": "link", "byproducts": {}, "command": [], "environment": {}, "materials": {}, "name": "write-code", "products": { "foo.py": { "sha256": "74dc3727c6e89308b39e4dfedf787e37841198b1fa165a27c013544a60502549" } } } }
These two are pretty much the same (thank god, that's good!).
Out in-toto specification is different to our implementations, though. In our specification we define the field "command" as string not as an array of strings. See: https://github.com/in-toto/docs/blob/master/in-toto-spec.md#44-file-formats-namekeyid-prefixlink
"command"
Is it safe to fix this in the specification or do we need to change our implementations? We did not reach in-toto 1.0 yet..
By the way. The same applies to the "expected_command" field in the layout file.
"expected_command"
I think we can safely update the specification to use a slice rather than string. Could you submit a patch?
While investigating https://github.com/in-toto/in-toto-golang/issues/124 I think I have found a bug in our specification.
The question is: What happens when the "command" section in the link file is empty? (Vice versa with "expected_command" for the layout file).
In our Golang implementation such case looks like this right now:
Our python implementation has the following link:
These two are pretty much the same (thank god, that's good!).
Out in-toto specification is different to our implementations, though. In our specification we define the field
"command"
as string not as an array of strings. See: https://github.com/in-toto/docs/blob/master/in-toto-spec.md#44-file-formats-namekeyid-prefixlinkIs it safe to fix this in the specification or do we need to change our implementations? We did not reach in-toto 1.0 yet..