filesystemlog.json records no content digest, so 377 logged files -- including 57 signatures and 3 served APKs -- have no hash anywhere in the log

[MarkovianProtocol]

repo/filesystemlog.json records six fields per file: size, two timestamps,
mode, uid and gid. No digest. Where the index also covers a file that is
harmless, because index-v2.json carries sha256 and the index is in the log.
Where the index does not cover it, there is no hash in the log at all.

Counted over today's HEAD (bc470e9): 942 entries in repo/filesystemlog.json,
565 of which appear with a sha256 in repo/index-v2.json, and 377 of which
do not. The 377 are 281 .png, 57 .asc, 19 .json, 11 .sig, 3 .jar,
2 web files, and three APKs -- Checkey-0.1.2.apk, LocationPrivacy-0.2.apk
and LocationPrivacy-0.3.apk. All three are still served; a range request to
each returns 206.

Worked instance, so this is not an inference: I downloaded
https://guardianproject.info/fdroid/repo/Checkey-0.1.2.apk. It is 842,881
bytes, matching the size in filesystemlog.json exactly, and its sha256 is
754701dbac52de5ca3930c2393970c03ef9aa07d1456911e9bf254d6014e0645. That string
does not appear anywhere in HEAD. So for that file the README's "check that any
file that they received ... was a publicly released file" holds up to filename
and byte count, and any 842,881-byte file named Checkey-0.1.2.apk passes every
check this log supports.

The .asc files are the ones I would fix first: they are the detached OpenPGP
signatures over the APKs, the artifact a user checks with. A digest field in
filesystemlog.json closes all 377 without changing the shape of the format.

Much smaller, same file tree: repo/index.jar.HTTP-headers.json,
repo/index.xml.HTTP-headers.json and archive/index.jar.HTTP-headers.json
last changed 2017-04-06 and still carry "Date": "Thu, 06 Apr 2017 21:33:18 GMT". Alongside an index-v2.json that updates daily they read as current
evidence of what the server served, and they are nine years old.

Drafted with AI assistance.