zentralopensource / zentral / 39458801854

91%

push

github

turbo: does the storage agree? the second axis

When the agent reports an upload, Zentral asks the storage about the object at
that key. It compares the size, and every digest that the storage recorded with
the one that the agent declared at the mint.

The two values reach that comparison by two independent paths. One went out at
the mint: S3 refused any body that did not match the values signed into the
upload, and the hosted destination checks the SHA-256 itself. It comes back as
the digest that the storage recorded. The other came home in the result.
Verification is where the two copies meet, and on S3 and GCS Zentral reads no
part of the file to do it. Only the file system storage, which records no
digest, reads the object back.

upload_digests publishes the digests that the storage records, except the
SHA-256, which the agent always computes: crc64nvme on S3, crc32c on GCS. On GCS
the agent then declares a CRC32C at the mint, and verification compares it with
the one that GCS recorded. Verification has no branch for a storage.

Both legs are checked. An agent whose result contradicts its own mint is
describing a different file, and comparing the stored object against the mint
alone would miss it — on a signing storage that comparison is nearly
tautological, since S3 enforced it on the way in.

verified / mismatch / missing lands on the row's own field, next to the status
and never instead of it, and rides the echoed entry into the result event as
`verification`, the verdict itself. The event now also carries run.id — what an
upload row is keyed on, without which the event describes an artifact nothing
can find.

Some answers are not answers, and none of them is recorded. A storage that timed
out, a key we may not read, an object with no stored digest, and an upload with
no declared digest to compare all leave the row pending, with a log entry: a
transient blip that marked artifacts permanently missing would be worse than no
answer at all. On a st... (continued)

60 of 60 new or added lines in 2 files covered. (100.0%)

53960 of 59205 relevant lines covered (91.14%)

0.91 hits per line