encode return value as integer instead of string

[shibumi]

The in-toto python reference implementation encodes the return-value
field of our link files as integer. Our specification specified this
field as string value. This commit fixes this inconsistency and
assigns the right data type to the return-value field.

CC: @SantiagoTorres @lukpueh @trishankatdatadog

[shibumi]

One open question is, how do we want to handle null values? Right now I have just assigned null to the example of the link file, underlining that return-value is an integer object and not a string (the value " " would be wrong in this case). Practically, I think we never have no return value, right?

[lukpueh]

LGTM. I agree with @shibumi that it makes sense to recommend int and null, especially since that's what we expect in the reference implementation.

[lukpueh]

Maybe @SantiagoTorres wants to make the final call. :)

[shibumi]

@SantiagoTorres @lukpueh I have force pushed a new version + I have modified the commit message, that it's clear we have also removed one return-value line that was a remainder.

[lukpueh]

Maybe @SantiagoTorres wants to make the final call. :)

re-ping @SantiagoTorres

[adityasaky]

I think this change looks good to me, and would represent the present behaviour in in-toto-python and in-toto-golang. Would we need to make any changes to record return-value as null if it isn't recorded?

[shibumi]

@lukpueh still need to withdraw his request for changes or click on 'approve', if this should get merged :)

[lukpueh]

Would we need to make any changes to record return-value as null if it isn't recorded?

Good question. in-toto-run always records a return-value in both implementations. in-toto-record (only available in the reference implementation) returns an empty byproducts field. Given that this is only a recommendation, I think we are fine either way.

[lukpueh]

Thanks for taking care of this, @shibumi!

[adityasaky]

Agreed, @lukpueh. LGTM!