[SCITT] Re: New draft: The Coverage Attestation Profile (draft-hillier-coverage-attestation-00), and a request to break it

[Joel Hillier <[e-mail]>]

Hi Emek, all,

Your seventh point is right, and I ran it against my own package rather than agreeing with it.

The six points fix the bytes of each line and say nothing about what the path in the line is relative to. Here is the test on the ARP archive: 27 files, one degree of freedom, three readings. These are the values under the six points alone, with the root unstated, which is the construction as published this morning:

be6c80f9e6835d5be46b9dbc7c156667fa0b140883c794edb17da1704005addd   root = the package root
f80caf1a20f7f2f44a448bb4982a5e8a970ee5aa85e6efff363e112e0aa04f27   root = one level above it
a5f34c00491da021361fa026126718eca9ab57eb5a05db571663943f341c8404   paths written as ./x

Three values. And a second run makes the mechanism explicit: with the root declared, those same three readings still produce three digests. Naming the root is what makes one of them the answer, not what makes the other two disappear. The declaration is the whole of it.

So the six points were written to close a degree of freedom in a sentence, and the artefact built to carry them left the same class of freedom one level down. That is the result I'd keep from this rather than the hole itself: a construction stated to close an ambiguity has to be tested against an artefact before the statement counts as the closure. Both of us have now had a repair need its own repair inside two days, from opposite directions, which is a fact about the method rather than about either tree.

Adopted, with your wording. The path is relative to a named root, and the root is published beside the digest. Mine is now the first line of the manifest itself rather than only in the covering message, because a root stated in an email is a root that doesn't travel with the bytes:

# root: the package root, the directory containing draft-hillier-scitt-arp.md and conformance/
<sha256> <path>
...

The header sits inside the digest, so the root can't be restated after the fact without moving the value. New digests are on the other thread with the archive.

Yours, for the record, is ce88ddfc0feaec90... over the fifteen at 0980d32 enumerated from manifest.json, root cap-1/src/vectors. With the root named that is reproducible rather than guessable, which is the first time this week that sentence has been true of a class digest in either direction.

The line endings, resolved, and thank you for chasing it down. core.autocrlf=true at system level, the Git for Windows installer default, invisible in any repository-local config. Two files, one commit, two checkout settings: 32,544 to 33,272 bytes, and 4,128 to 4,218. The bundle isn't wrong and stored bytes with no normalisation is the right construction.

Your line about your own sentence is sharper than the finding: "reproduce exactly once line endings are normalised" described a repair for damage your own checkout had done, and it was one step from becoming a normalisation step in somebody's construction. That is how a canonicalisation rule gets born, and this one would have been born to undo a defect that was never in the data. It goes nowhere, as you ask.

On there being no script. That the value came from a computation run once and not kept is the more useful of the two answers. What was published was all that survived of a construction rather than a description of one, and neither of us could tell the difference from the sentence, which is precisely the property that sentence needed to have and didn't.

Forty-four failing is the correct outcome. Your line for it is better than mine: a forty-fifth that happened to land would have been worse, because then we'd both have believed the sentence. That is worth stating as a rule on its own. A construction that reproduces once has been confirmed by a coincidence; a construction that reproduces from its own statement has been confirmed by a reader. Only the second is evidence, and at the moment it happens the first is indistinguishable from it.

Your path-blind correction, checked against my probe rather than assumed. You're right that a digest committing to the multiset has to order the digests and not the paths, and that your first variant ordered by path and then dropped them, which is a third construction rather than the path-blind one. Mine reads, verbatim:

        ds.append(hashlib.sha256(open(fp, "rb").read()).hexdigest())
    return hashlib.sha256("\n".join(sorted(ds)).encode()).hexdigest()

It sorts the digests. So the mutant stands and your correction of yourself is right on both halves.

Worth naming what you actually did there, because almost nobody does it. You reproduced someone else's result, got a different answer, and went after your own construction first rather than theirs. The default in that position is to report the other party's mutant as wrong, and you'd have been believed, because it was my mutant in my bundle and I'd have gone looking in my own code.

Your three values under the seventh point. That paths-relative-to-the-vectors-directory, paths-relative-to-the-repository-root, and the-first-plus-manifest-as-a-sixteenth-member give three digests is the enumerated-member-set point and the named-root point turning out to be one point wearing two hats. Point one says never infer the member set from a directory listing. Point seven says never infer the root from where you happened to be standing. Both are the same instruction: an enumeration is not a fact about a filesystem. I'd merge them in any shared text rather than list them separately, because separately they read as two conveniences and together they read as one rule.

Joel