@me Thinking to build a prototype for https://github.com/captn3m0/ideas#verifiable-code-execution-on-cloud.

Plan:

1. Trigger the lambda.
2. Hold it (long-polling as above)
3. Validate the lambda configuration to trust the execution environment. Things like: Correct code, no cloudtrail/telemetry/extensions on lambda/validate ingress guarantess/check for traffic mirroring etc. This happens via a second aws account that has read permissions on the execution account.
4. Finally, once trust is established, pass the actual data to the lambda.

@me It has to be the same lambda invocation to avoid TOCTOU concerns - the lambda code or environment being changed between the validation and execution steps.

@me Good point - (thinking..) So you run a wrong copy, but incorrectly validate it as correct because the code was updated in the interim.

Could be guarded against by checking for any recent changes as untrustworthy perhaps. Only changes/configuration older than your invocation initiation should be valid. If it fails, we don't send the data.

@nemo if this is ultimately built on trusting AWS, then function versions are usually immutable

://docs.aws.amazon.com/lambda/lat

This could also be extended to docker image hashes too theoretically.

@me I thought you could overwrite a given “revision”.

There isn’t a way to invoke a function via a specific immutable version or hash identifier afaik.

The challenge is to find the smallest AWS construction that would allow this. Docker forces ECR, which brings a bigger surface area, but definitely under consideration.

@nemo from their docs it _seems_ like you can't update the code for a given version number. It'll monotonically update the version with each code deployment. They have function alias which are named version, but those are separate (it seems)

Also each version has it's own ARN, so you can invoke a specific version of the function via aws's invoke API potentially.