Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checkpoint spec compliance: Mismatched origin string with signature #2069

Open
haydentherapper opened this issue Apr 4, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@haydentherapper
Copy link
Contributor

haydentherapper commented Apr 4, 2024

Context

Even though Rekor looks like a single log, it's backed by multiple trees, so that we can periodically shard the log to prevent indefinite growth. When verifying inclusion proofs, you use a tree-specific index for example. When verifying checkpoints, you use the tree size, not the total log size.

Problem

Here's the current checkpoint:

rekor.sigstore.dev - 2605736670972794746
79317123
Kmb+leehFHcnu5BxZCMqengfUR/yhOQuNcDE7kzmb94=

— rekor.sigstore.dev wNI9ajBFAiEAlMvpqFXBNC2hHHclvkSF3F/IwJWifmpJbqFSlHeur/kCIAiLLyjtqi/UhXl/PgIgnsFTP34doSOUYE00BXeS+GH1

Note the first line, rekor.sigstore.dev - 2605736670972794746, is the unique identifier for the tree. It appends the tree ID 2605736670972794746 to make the checkpoint unique.

Each signature line should start with the identifier for either the log or the witness that signs it. In this case, it's rekor.sigstore.dev, which is only the hostname, not the log origin. The first signature's identifier should match the origin string.

I'm surprised this was never noticed actually, because the log is being monitored by the omniwitness project. I guess the signature origin was never compared to the checkpoint origin.

Proposal

Change the identifier on the signature line to match the origin string.

Clients

I think we're good to make this change without any impact to clients. Looking over each client:

While out of scope for this issue, I wanted to mention that the next time we shard, we will plan to change the origin string to be more URL like as noted in #1450. Clients should not make any assumptions on the format of the string. I don't see any assumptions currently, so we're good to go.

@haydentherapper haydentherapper added the enhancement New feature or request label Apr 4, 2024
@haydentherapper
Copy link
Contributor Author

Investigating further, it appears a lot of known logs don't follow this. This might be considered a breaking change from the perspective of the witness. Looking into it...

@haydentherapper
Copy link
Contributor Author

Given this will be a breaking change to witnesses and there is nothing mandating a matched origin and signature identifier, we won't move forward with making any changes for the existing shard. We'll make this change during the next sharding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant