sigstore: stream input into signing

[woodruffw]

WIP; needs test updates and equivalent changes to verification.

Closes #158.

Signed-off-by: William Woodruff [email protected]

[woodruffw]

Flagging for thoughts here: it's possible that, once we make the signing and verification APIs public, a user could decide to be clever and decide to do something like this:

signer.sign(socket_io, identity_token)

...where socket_io is a file-like handle for a network connection. If the signer doesn't control the server or the network itself is untrustworthy (i.e., the transport itself is insecure), an attacker could truncate the streaming input and produce a digest other than the one expected, which in turn would be signed by the given identity.

This in turn could result in valid digests for malicious messages, e.g. for an input structure that looks something like this:

S: IMPORTANT PIECE OF INFORMATION THAT REQUIRES CONTEXT TO FOLLOW

<- attacker truncates stream here

S: IMPORTANT CONTEXT THAT MUST ALSO BE SIGNED

I think we have a couple of options here:

1. Define this to be out-of-scope/outside of our threat model: sigstore-python operates primarily on local files (and that's all the CLI supports), where these kinds of truncation attacks are more complicated (and any sufficiently empowered attacker can probably just pass a malicious input in instead).
2. stat or ftell the source before streaming from it, and fail if the ultimate number of bytes read doesn't match the result. This will probably prevent usage with raw sockets entirely, since sockets don't have fixed input sizes. It would however allow usage with a sufficiently smart file-like object, like an HTTP client that provides the size via the HTTP headers.

[woodruffw]

cc @znewman01, since you may have already run into this on cosign (or it may become a similar design consideration in the near future!)

[di]

I think this is a bit outside our threat model, but if 2) is relatively easy, we should do that just to be safe. I have doubts on how well this will work cross-platform, though.

[woodruffw]

Yeah, agreed. I'll leave it as-is for now, with a justifying comment.

[di]

LGTM. An example in the docs would be nice.

[woodruffw]

An example in the docs would be nice.

What kind of example are you looking for? This doesn't change the CLI at all, only how we plumb its arguments into the API, so I might be missing something 🙂

[di]

An example in the docs would be nice.

Sorry, I meant: some documentation of our discussion, which you did. Thanks!