transparency-dev / serverless-log Goto Github PK

The GCP log implementation uses request preconditions to address race conditions.

Case 1:

Tile write failure: implemented in #70.

Entries have been sequenced successfully, but when Integrate runs, writing a tile (partial or full) somehow results in a tile that is different that the one that has already been written. This should not happen.

Case 2:

Checkpoint write failure: implemented in #61.

If there is a race condition in Integrate, one run will fail because the checkpoint will have changed by the time it wants to write its version of the checkpoint. This may happen in race conditions. Since Integrate is idempotent, you just need to invoke the Cloud Function again.

If you are invoking the functions from Cloud Build (as we are in the Armored Witness project), the log operator will need to manually retry the Integrate step of the Cloud Build config that failed OR the log will not be updated until the next time an entry gets added and Sequence and Integrate are invoked. It is okay for the latter to happen wrt integrity of the log; the only consequence is that the log will not include the failed run's entry until the next Integrate call.

It's an edge case, but one I just hit. For an empty log checkpoint (size 0) I got the following error:

failed to create proof builder: invalid checkpoint hash e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, expected

I believe this is from https://github.com/transparency-dev/serverless-log/blob/main/client/client.go#L115

Triggering checkpoint:

transparency.dev/armored-witness/firmware_transparency/ci/1
0
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

— transparency.dev-aw-ftlog-ci 9UecHqNZRspvlnqtGMydkw9WC9l3iKU6myILmi2PzzObAnWzZZXXdWC+GFb9EfhMlrgme1IMeAlq8EacCm7R7JWXngo=