[issue] Sharding broke client logic when verifying consistency with inactive shards

[asraa]

Description

Hi, there is another distinct sharding issue (beyond the inactive shard lookup) we found in the SLSA GitHub Generators: slsa-framework/slsa-github-generator#942

In our verification flow (at that verifier version: note there was no STH available in an returned entry) for an entry in Rekor, we do the following:

1. Check the inclusion proof with the hashes against the root hash given in the entry verification.
2. Check that the inclusion proofs root hash is consistent with a signed tree head (STH)
3. Verify the SET

In step 2: we would retrieve the current STH and verify consistency up to that. Obviously, our clients were not shard aware, and this broke, because the STH refers to the active shard, not the shard the entry was on.

I understand NOW I can check against an STH delivered in the entry return response (@haydentherapper added?). I also know that LogInfo returns inactive shard info.

Now my question, as I'm trying to backport fixes into this (which users are currently using: slsa-framework/slsa-github-generator#942) is: how can I identify the inactive shard an entry was on?

The models.LogEntryAnon.LogID is the sha256 of the DER encoded pubkey of the shard like c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d. The shard tree IDs are integers like "treeID":"3904496407287907110". As a client, how am I supposed to do this?

@priyawadhwa

Version

[asraa]

@loosebazooka helped me out here: I can use the prepended tree ID from the returned entry UUID

[asraa]

Leaving this as a record of clients breaking because they were not notified of needing to be sharding-aware though.

[haydentherapper]

Related: sigstore/rekor-monitor#57

Also broke omniwitness