borg2: index rebuild trusts pack headers

[ThomasWaldmann]

IIRC the pack headers are not authenticated when it rebuilds the index.

[mr-raj12]

The rebuild walks pack headers via PackReader.iter_headers() and trusts them as-is: no magic/version check, and it uses meta_size/data_size to step to the next object, so a corrupted size silently mis-indexes the rest of the pack. Nothing gets decrypted during the walk, so the header AAD is never exercised. This runs on check --repair (slow_rebuild=repair) and on the non-repair rebuild fallback too.

Worth noting the AAD only helps for the AEAD keys. authenticated/none ignore aad and rely solely on assert_id (a full-plaintext rehash), so there's no cheap header-only check for those modes.

so, before trusting a pack's headers, verify store.hash("packs/"+name) == name. That authenticates every header byte at once, works for all key modes, needs no key, and is server-side/free on REST (full pack read on local/ssh). Packs already certified via the checked-packs tracker (#9897) could be skipped, and this fits into the #10026 repo-repair work.

wanted a note on whether the goal only is to catch repository-side corruption/tampering (the pack-hash gate covers that), or also evil-client forgery? The latter needs --verify-data and is out of scope for rebuild.

[ThomasWaldmann]

• sha256 pack verification is NOT authentication, it is just protecting against accidental damage (not against tampering by an attacker)
• we don't optimize for none/authenticated mode, these are low-security modes
• it could fetch/decrypt (AE with AAD) the metadata from the repo object - that is not much (much less than in --verify-data, were we also verify the data) and proves (if decryption succeeds) that the ID is correct. hmm, maybe an attacker could still swap the data part and we would not notice while index-building.
• as a simple check and an indication that we're not off-tracked by a wrong offset, it could also check the magic