Differences between the in-toto implementations and the specification

[shibumi]

While investigating in-toto/in-toto-golang#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

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..

[shibumi]

By the way. The same applies to the "expected_command" field in the layout file.

[adityasaky]

I think we can safely update the specification to use a slice rather than string. Could you submit a patch?

[adityasaky]

#69