A couple weeks ago I published an atproto-focused survey of apps and libraries' handling of CAR contents:

CAR bodies are blocks of len || CID || bytes, where each CID is supposed to correspond to the bytes that follow it. Most CAR libraries do not check this, which is really surprising to most devs, especially in atproto where there is only one hash type allowed for the CID (sha-256). The result is that lot of apps that attempt to authenticate contents end up authenticating everything except the contents.

DASL-CAR is a big step in the right direction: it only allows DASL-CIDs, which only allow SHA-256, so DASL-CAR libraries tend to auto-verify. This is great! Hopefully atproto apps will gradually move from IPLD-CAR libraries toward safer DASL ones. Until then...

Repair progress

The good thing about this specific driving hazard is that it can be fixed! I'll try to keep this post updated with ecosystem progress since that initial survey. Please let me know if I've missed any!

CAR libraries

🐸 @atcute/car now verifies blocks against CIDs while reading, since v6.10!

atproto libraries

🌱 @atcute/repo now rejects records with mismatched CIDs by default in all read APIs, since v1.1.0!

🍀 hydrant now enables CID verification by default!

Corrections

🎄 Bluesky's typescript firehose consumer does explicitly turn off verification (basis for the original no-verify claim), but only on a second read of the same CAR contents: the first pass should fail for any mismatched blocks. Note: I still haven't done a complete POC or full correctness verification here, but I think the original claim was wrong.

🍏 wisp.place was marked "not verifying" since it uses the bluesky typescript firehose consumer, so the same correction applies. Sorry!

🌼 hydrant was marked as only verifying CIDs on read paths, but it did also have verification on the ingest paths, but not enabled by default. Sorry for the misleading summary! (and it has since been enabled by default!! 🍀)