"Multi-stage" attestation support

[mikhailswift]

There are times where we may want to capture multiple commands in a singular attestation file. For example with the Gitlab runner integration currently a gitlab job with multiple commands in it's script will create an attestation for each command:

script:
- cd src/
- echo "something"
- go build ./...

Will result in three separate attestations for each of the commands in the job's script.

This is somewhat undesirable as attestations for cd src/ and similar aren't incredibly useful and generally when creating policy we really want to enforce that the entirety of the CI job's script block executed.

The in-toto python implementation supports this with in-toto record start and in-toto record stop. Witness could do something similar and add a concept of multi-stage attestations.

This may look like starting a witness "session" which would run all of the pre-command attestors and store them in a partial attestation collection. Then, each subsequent command could append to this partial collection for each command run in the "session". Afterward the "session" could be ended and all of the post-command attestors could run on the results of the session and finalize the collection.

At each step of the session the partial attestation collection will need to signed after modification and verified before appending.

Modifications to the attestation lifecycle may need to be made and will need to be decided upon. For instance we may require some re-work of how attestors are represented and the lifecycle to support capturing the products and traces of each command that runs as opposed to the singular command we currently capture.

[colek42]

I'd like to do a high-level threat model against this before we start work, specifically attacks on the file holding the context and the system clock.

[mikhailswift]

We definitely need to dive into it but just a few quick thoughts:

• The file would be in a signed envelope like any other collection so the threat model shouldn’t be much different compared to any other collection we currently generate.

• We shouldn’t be trusting the system clock at any point for anything currently and that shouldn’t change here