Merkle tree proof implementation #285

vembacher · 2023-07-19T08:40:43Z

Summary

Related to: #283

This adds implementations for:

consistency proofs
inclusion proofs
checkpoint/STH related functionality

The Merkle proofs are essentially ports of the transparency-dev implementations, including the test suite.
The checkpoint related code is based on the implementation in the rekor Go package.

I also changed the Rekor models to use the new SignedCheckpoint type, which implements the serde traits. For now I think this is the only major breaking change, the rest are mostly new or private APIs.

I have not implemented the logic to verify that Checkpoints and the corresponding consistency/inclusion proof are sound together. I want to discuss how to handle this here.

Release Note

added functions to relevant Rekor models to support the verification of Merkle inclusion and consistency proofs
added addition variants to SigstoreError enum
added Checkpoint type to handle verification of checkpoints/STHs
changed type of signed_tree_head fiekd from String to Checkpoint
added field checkpoint: Option<Checkpoint> to InclusionProof struct

Documentation

relevant new features are documented via RustDoc or examples
breaking changes primarily affect LogInfo and LogEntry due to changes to struct fields, this should only require minor changes

Todos:

add examples
add tests for Rekor models verification functions
write change-log
discuss how to verify that checkpoint + proof are valid together
update Summary, Release Notes, Documentation once code is finalized.

lukehinds · 2023-07-20T08:19:15Z

One for the TODO would be something for examples/

Nice work btw!

vembacher · 2023-07-21T09:11:53Z

I added examples for consistency and inclusion proofs.

I will also add some tests in the future to the methods I added to the Rekor models. What test data should I use for this? As these require log entries + keys.

Also I'm unsure whether my checks to ensure whether proofs and checkpoints are valid together are correct. What is the correct way to do this?

flavio · 2023-09-07T08:08:02Z

Sorry, this has been sitting on my review list for a long time. I need some time to get familiar with the feature being implemented 😓

vembacher · 2023-09-19T06:27:19Z

Sorry, this has been sitting on my review list for a long time. I need some time to get familiar with the feature being implemented 😓

No worries! I'm not in a rush to complete this.

gaetanww · 2024-02-14T12:27:14Z

I received an error with the current implementation when I tested for the entry with index 25579.

Problem

I received the following error although the verification should have succeeded.

InclusionProofError(MismatchedRoot { expected: "db0822d0508b54bfb770ba5d3394d331bd9a22c91d9a8c0b906e7ea2208903be", got: "4d006aa46efcb607dd51d900b1213754c50cc9251c3405c6c2561d9d6a2f3239" })

Underlying problem

The underlying error is, I believe, related to the assumption that the body is formatted as canonical JSON when it is appended to the log. Indeed, to verify that the body is included in the merkle tree, the implementation currently reserializes the body using a canonical formatter. However, I think the original entry wasn't formatted using a canonical formatter (see files below).

To fix

We can't make the assumption that the body was formatted canonically, so I think the solution should be to keep the "original" base64-decoded body as bytes in the LogEntry struct and use this to verify the inclusion proof instead of reserializing it.

If you agree with the fix, I'm happy to work on it.

To reproduce

The following code:

let rekor_config = Configuration::default();
let rt = tokio::runtime::Runtime::new().unwrap();
let log_entry = rt.block_on(get_log_entry_by_index(&rekor_config, 25579)).unwrap();
let mut encoded = vec![];
let mut ser = serde_json::Serializer::with_formatter(
    &mut encoded,
    olpc_cjson::CanonicalFormatter::new(),
);
log_entry.body.serialize(&mut ser).unwrap();
println!("{}", String::from_utf8(encoded).unwrap());

returns:

{"apiVersion":"0.0.1","kind":"rekord","spec":{"data":{"hash":{"algorithm":"sha256","value":"ce9a7c82f32194995888758cf107ef0cc52e0b8cdce73b4240658ee9e73783cb"}},"signature":{"content":"MGUCMD3oKzgsGnPAkJEXegDIsdlh4BFCQbM6jng4Sy3axY/+2tlK97oe/CkxabT1ZXUqCAIxAJDq+zLfRZZEJD5DvaKhFEu+Jm+jD4UXc3CaZp2MSajiralmtalA6fSGCXjwGfUzOw==","format":"x509","publicKey":{"content":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrakNDQWhpZ0F3SUJBZ0lVQU0rK0dYRFN5bUNPSW82YmxMMG5EZngxb21nd0NnWUlLb1pJemowRUF3TXcKS2pFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUkV3RHdZRFZRUURFd2h6YVdkemRHOXlaVEFlRncweQpNVEEzTWpnd09ETTNOREphRncweU1UQTNNamd3T0RVM05ERmFNQUF3ZGpBUUJnY3Foa2pPUFFJQkJnVXJnUVFBCklnTmlBQVJjMDMrUU4vTHBrOGpqUFQwTmV5a01ucm9mMnpZUkJxNm05ei9TMXhRSzduZnZhU3grRjUrTEtwN3gKR2ExbHY2SWNvRXdwUHA2MUdsYnd5S0VQVWJLdzJrYnJyRVpPMnhKV3kxb0VEUHBYMlJqcTBYS0RZcEF5Zi9mQwoyZzJjSnVtamdnRW5NSUlCSXpBT0JnTlZIUThCQWY4RUJBTUNCNEF3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVICkF3TXdEQVlEVlIwVEFRSC9CQUl3QURBZEJnTlZIUTRFRmdRVTRBUDhtTkI4ejhSZFJyTVVLZ1A2Mm0xUFErd3cKSHdZRFZSMGpCQmd3Rm9BVXlNVWRBRUdhSkNreVVTVHJEYTVLN1VvRzArd3dnWTBHQ0NzR0FRVUZCd0VCQklHQQpNSDR3ZkFZSUt3WUJCUVVITUFLR2NHaDBkSEE2THk5d2NtbDJZWFJsWTJFdFkyOXVkR1Z1ZEMwMk1ETm1aVGRsCk55MHdNREF3TFRJeU1qY3RZbVkzTlMxbU5HWTFaVGd3WkRJNU5UUXVjM1J2Y21GblpTNW5iMjluYkdWaGNHbHoKTG1OdmJTOWpZVE0yWVRGbE9UWXlOREppT1daallqRTBOaTlqWVM1amNuUXdIZ1lEVlIwUkFRSC9CQlF3RW9FUQpZM1JoWkdWMVFHZHRZV2xzTG1OdmJUQUtCZ2dxaGtqT1BRUURBd05vQURCbEFqRUE3TTJwSzhRUFRrSGs1bzZ0CmdnampZdjBLV1BUajRKUTAwU3RjR0xqa1g3SU1iNC9HdXpYRkQ4czZDOEd3NmpwMEFqQW1Xa2JROTVsMzlnUGQKR2pjUjBSQURaT0dYb0NPQURwOE5lSzhBL2dKdWdnR0ZINHZYZ2l1ODJsQm5MOEZSc09jPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="}}}}

when a direct call to the api:

curl 'https://rekor.sigstore.dev/api/v1/log/entries?logIndex=25579' | jq -r '.[ (keys_unsorted)[0] ].body' | base64 -d

returns:

{"apiVersion":"0.0.1","spec":{"data":{"hash":{"algorithm":"sha256","value":"ce9a7c82f32194995888758cf107ef0cc52e0b8cdce73b4240658ee9e73783cb"}},"signature":{"content":"MGUCMD3oKzgsGnPAkJEXegDIsdlh4BFCQbM6jng4Sy3axY/+2tlK97oe/CkxabT1ZXUqCAIxAJDq+zLfRZZEJD5DvaKhFEu+Jm+jD4UXc3CaZp2MSajiralmtalA6fSGCXjwGfUzOw==","format":"x509","publicKey":{"content":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrakNDQWhpZ0F3SUJBZ0lVQU0rK0dYRFN5bUNPSW82YmxMMG5EZngxb21nd0NnWUlLb1pJemowRUF3TXcKS2pFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUkV3RHdZRFZRUURFd2h6YVdkemRHOXlaVEFlRncweQpNVEEzTWpnd09ETTNOREphRncweU1UQTNNamd3T0RVM05ERmFNQUF3ZGpBUUJnY3Foa2pPUFFJQkJnVXJnUVFBCklnTmlBQVJjMDMrUU4vTHBrOGpqUFQwTmV5a01ucm9mMnpZUkJxNm05ei9TMXhRSzduZnZhU3grRjUrTEtwN3gKR2ExbHY2SWNvRXdwUHA2MUdsYnd5S0VQVWJLdzJrYnJyRVpPMnhKV3kxb0VEUHBYMlJqcTBYS0RZcEF5Zi9mQwoyZzJjSnVtamdnRW5NSUlCSXpBT0JnTlZIUThCQWY4RUJBTUNCNEF3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVICkF3TXdEQVlEVlIwVEFRSC9CQUl3QURBZEJnTlZIUTRFRmdRVTRBUDhtTkI4ejhSZFJyTVVLZ1A2Mm0xUFErd3cKSHdZRFZSMGpCQmd3Rm9BVXlNVWRBRUdhSkNreVVTVHJEYTVLN1VvRzArd3dnWTBHQ0NzR0FRVUZCd0VCQklHQQpNSDR3ZkFZSUt3WUJCUVVITUFLR2NHaDBkSEE2THk5d2NtbDJZWFJsWTJFdFkyOXVkR1Z1ZEMwMk1ETm1aVGRsCk55MHdNREF3TFRJeU1qY3RZbVkzTlMxbU5HWTFaVGd3WkRJNU5UUXVjM1J2Y21GblpTNW5iMjluYkdWaGNHbHoKTG1OdmJTOWpZVE0yWVRGbE9UWXlOREppT1daallqRTBOaTlqWVM1amNuUXdIZ1lEVlIwUkFRSC9CQlF3RW9FUQpZM1JoWkdWMVFHZHRZV2xzTG1OdmJUQUtCZ2dxaGtqT1BRUURBd05vQURCbEFqRUE3TTJwSzhRUFRrSGs1bzZ0CmdnampZdjBLV1BUajRKUTAwU3RjR0xqa1g3SU1iNC9HdXpYRkQ4czZDOEd3NmpwMEFqQW1Xa2JROTVsMzlnUGQKR2pjUjBSQURaT0dYb0NPQURwOE5lSzhBL2dKdWdnR0ZINHZYZ2l1ODJsQm5MOEZSc09jPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="}}},"kind":"rekord"}

Note that the the "kind" field is at the end of the json in the API and in second place in the canonicalized format.

tnytown · 2024-02-16T06:13:22Z

Thanks for the thorough triage @gaetanww!

I won't speak too much on this as I haven't tried this out myself, but I suspect that the issue you're seeing regarding canonicalization may be related to the canonicalizer being used. This implementation currently uses olpc_cjson, while Rekor uses RFC 8785 canonicalization. (OLPC canonical JSON is regrettably distinct from RFC 8785 canonical JSON.) In the sign module, we've used json-syntax to canonicalize the LogEntry body in accordance with RFC 8785 rules.

gaetanww · 2024-02-16T09:46:34Z

np! Thanks for the pointer, yes that could be it. I think the following code should work (using the json_syntax crate with features ["canonicalize", "serde_json"]). I won't have time to try it out today though.

pub fn verify_inclusion(&self, rekor_key: &CosignVerificationKey) -> Result<(), SigstoreError> {
        self.verification
            .inclusion_proof
            .as_ref()
            .ok_or(UnexpectedError("missing inclusion proof".to_string()))
            .and_then(|proof| {
                // encode as canonical JSON
                let mut json_value = json_syntax::Value::from_serde_json(serde_json::to_value(&self.body)?);
                json_value.canonicalize();
                let encoded_entry = json_value.compact_print().to_string().into_bytes();
                proof.verify(&encoded_entry, rekor_key)
            })
    }

vembacher · 2024-02-16T09:53:28Z

I hopefully should be able to take a closer look at this some time next week, and apply the fix/update the PR.

gaetanww · 2024-02-16T16:28:56Z

One more data point on issue above. It works perfectly without modification with index: 71844338, however, my hand-rolled merkle tree verification now fails. My hand-rolled implementation is just using the b64 decoded body in the json, so the underlying issue might not be canonicalization.

vembacher · 2024-02-16T16:50:02Z

I haven't looked at it in a few months, but if I remember correctly there are two types of indices. With one being the index in the log and one being the index in the tree. So you might be using the incorrect index.

vembacher · 2024-02-28T08:16:04Z

@gaetanww is your issue resolved?

gaetanww · 2024-03-18T14:39:08Z

Sorry for the slow response. I made it work for the latest rekor records (e.g., index 71844338), the early one (25579) still fails AFAICT.

vembacher · 2024-03-18T16:18:38Z

I did some investigating, I think @gaetanww your original analysis was correct and the formatting of the log entry is the issue, as both serializers produce identical outputs for me.

The Go client also uses the Base64 encoded entry provided by the log, is this the correct way to handle this? I feel like this might conflict with the description on how SETs are supposed to be verified.

gaetanww · 2024-03-18T17:25:17Z

Yes, the documentation does conflict with the actual definition. There should at least be a comment in the go code to explain why it's implemented that way.
I think we should raise the point with the maintainers of the cosign project. I'll open an issue.

Relates to: sigstore#283 Signed-off-by: Victor Embacher <victor@embacher.xyz>

…added some functionality. Relates to: sigstore#283 Signed-off-by: Victor Embacher <victor@embacher.xyz>

Signed-off-by: Victor Embacher <victor@embacher.xyz>

…tions. Signed-off-by: Victor Embacher <victor@embacher.xyz>

Signed-off-by: Victor Embacher <victor@embacher.xyz>

exFalso · 2024-06-06T14:13:52Z

This is failing on 32bit targets because of the use of usize for bitwise arithmetic. Changing to u64 fixes it.

tannaurus · 2024-08-06T14:37:50Z

Howdy 👋 is there someone in the community equipped to adequately review this MR? We at 1Password would be happy to review elements of this work but the core team that has directed energy towards this project doesn't have previous experience with merkle tree proof implementations.

loosebazooka · 2024-08-13T18:09:51Z

@tannaurus I'm going to look at the merkle tree proof as I previously did a lot of work on a different client there. However I would need someone else to do the rust review.

vembacher · 2024-08-19T09:23:42Z

This is failing on 32bit targets because of the use of usize for bitwise arithmetic. Changing to u64 fixes it.

@exFalso

I will update it to u64, it seems like RFC6962 also prescribes a uint64.

Signed-off-by: Victor Embacher <victor@embacher.xyz>

loosebazooka · 2024-08-20T01:09:34Z

Sorry my ability to read rust is bad.

I'm a little confused by the edits in rekor/models -- those seem like generated files? But the added code doesn't seem generated? Maybe I'm just reading rust wrong.

The inclusion proof looks like its following the spec in 6962, there's a slightly different implementation in 9162 -- I don't know if it matters but it's not recursive.

It might be valuable to add some tests on the rekor inclusion proof itself (rather than the sub-functions):

one random example (from the java client):

      "inclusionProof": {
        "hashes": [
          "810320ec3029914695826d60133c67021f66ee0cfb09a6f79eb267ed9f55de2c",
          "67e9d9f66f0ad388f7e1a20991e9a2ae3efad5cbf281e8b3d2aaf1ef99a4618c",
          "16a106400c53465f6e18c2475df6ba889ca30f5667bacf32b1a5661f14a5080c",
          "b4439e8d71edbc96271723cb7a969dd725e23e73d139361864a62ed76ce8dc11",
          "49b3e90806c7b63b5a86f5748e3ecb7d264ea0828eb74a45bc1a2cd7962408e8",
          "5059ad9b48fa50bd9adcbff0dd81c5a0dcb60f37e0716e723a33805a464f72f8",
          "6c2ce64219799e61d72996884eee9e19fb906e4d7fa04b71625fde4108f21762",
          "784f79c817abb78db3ae99b6c1ede640470bf4bb678673a05bf3a6b50aaaddd6",
          "c6d92ebf4e10cdba500ca410166cd0a8d8b312154d2f45bc4292d63dea6112f6",
          "1768732027401f6718b0df7769e2803127cfc099eb130a8ed7d913218f6a65f6",
          "0da021f68571b65e49e926e4c69024de3ac248a1319d254bc51a85a657b93c33",
          "bc8cf0c8497d5c24841de0c9bef598ec99bbd59d9538d58568340646fe289e9a",
          "be328fa737b8fa9461850b8034250f237ff5b0b590b9468e6223968df294872b",
          "6f06f4025d0346f04830352b23f65c8cd9e3ce4b8cb899877c35282521ddaf85"
        ],
        "logIndex": 1227,
        "rootHash": "effa4fa4575f72829016a64e584441203de533212f9470d63a56d1992e73465d",
        "treeSize": 14358,
        "checkpoint": "rekor.sigstage.dev - 108574341321668964\n14358\n7/pPpFdfcoKQFqZOWERBID3lMyEvlHDWOlbRmS5zRl0=\n\n— rekor.sigstage.dev 0y8wozBFAiB8OkuzdwlL6/rDEu2CsIfqmesaH/KLfmIMvlH3YTdIYgIhAPFZeXK6+b0vbWy4GSU/YZxiTpFrrzjsVOShN4LlPdZb\n"
      },

and then another failure test where you mangle this data a bit.

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

Signed-off-by: Víctor Cuadrado Juan <2196685+viccuad@users.noreply.github.com>

viccuad

Hi everybody, many thanks to @vembacher and all the reviewers of this PR, it's been quite the journey! I'm infinitely glad for the effort you put in this PR.

I had a long ramp-up time on the cryptography and Merkle trees, and understanding the RFCs 6962 and 9162 this last week. After this, I can say I can understand the feature good enough to review it. The PR looks great to me in its core implementation. I have added some minor comments and pushed some changes to make it compile and pass linters, I hope it's ok. I found this the best way to try to move it forward.

There's some hurdles as it stands:

The format of consistency proofs as hex instead of base64 that @rozbb raised here. Non-blocker for me.
Reusing the upstream testsuite. Non-block for me, we can tackle that in a follow-up PR.
Rebasing onto main and correct DCO sign-off.

The PR has taken a long time, and I think it would be more productive to merge without further bigger changes, so we can build upon it. Hence, I'm approving.

We still need it to be mergeable though.

@vembacher: would you be ok with trying a rebase and correct DCO of this PR?
If not, I will take care of it by just fixing the conflicts, but potentially by opening a new PR with your changes already rebased.

Conflicts: Cargo.toml src/cosign/bundle.rs src/cosign/signature_layers.rs src/lib.rs src/registry/oci_caching_client.rs src/trust/mod.rs Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

Needs unimplemented DSSE model. Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

exFalso · 2025-11-21T12:26:46Z

A clarifying question: does/will this work with Rekor V2 tiling?

viccuad · 2025-11-24T13:08:23Z

A clarifying question: does/will this work with Rekor V2 tiling?

No, this is an implementation of Rekor Merkle tree approach, as it stands right now. Rekor v2 with tile trees will need to come later on.

flavio · 2025-11-26T15:26:40Z

src/rekor/models/checkpoint.rs

+            BASE64_STANDARD.encode([self.key_fingerprint.as_slice(), self.raw.as_slice()].concat());
+        format!("— {} {sig_b64}\n", self.name)
+    }
+    fn decode(s: &str) -> Result<Self, ParseCheckpointError> {


nit: I would add an empty line

Not a nit: add some documentation explaining what is the expected format. We could copy paste https://github.com/sigstore/rekor/blob/4b1fa6661cc6dfbc844b4c6ed9b1f44e7c5ae1c0/pkg/util/signed_note.go#L129-L140 and add a reference to it (the actual URL I just pasted).

I found https://github.com/transparency-dev/formats/blob/main/log/README.md#signed-envelope, which documents the signed_note format and the signature format, will add it to the functions.

Fixed in bc19a18.

flavio · 2025-11-26T15:27:25Z

src/rekor/models/checkpoint.rs

+        let [_, name, sig_b64] = s.split(' ').collect::<Vec<_>>()[..] else {
+            return Err(DecodeError(format!("unexpected signature format {s:?}")));
+        };


We are not making sure the line begins with \u2014, see here

Fixed in 5f29463.

flavio · 2025-11-26T15:30:49Z

src/rekor/models/checkpoint.rs

+            .map_err(|_| DecodeError("failed to decode signature".to_string()))?;
+
+        // first four bytes of signature are fingerprint of key
+        let (key_fingerprint, sig) = sig.split_at(4);


Do not use split_at since it panics if sig length is < 4.

Note split_at is also used elsewhere, please replace it with split_at_checked

Fixed in 61a2158. Didn't find any other similar occurrence.

flavio

Initial round of reviews, I still have to go through some files of the PR

flavio · 2025-11-26T15:54:41Z

src/rekor/models/checkpoint.rs

+            return Err(DecodeError("unexpected checkpoint format".to_string()));
+        };
+
+        let signature = CheckpointSignature::decode(signature)?;


A checkpoint can have multiple signatures:

checkpoint format spec

Go code parsing all the signatures

Go SignedNote.Signatures type definition

Fixed in f68128d.

flavio · 2025-11-26T16:02:09Z

src/rekor/models/checkpoint.rs

+    pub(crate) fn encode(&self) -> String {
+        let note = self.note.marshal();
+        let signature = self.signature.encode();
+        format!("{note}\n{signature}")


I think this encoding is wrong, it should be:

{note}\n\n{signature}

note.marshal produces a string that is not terminated by \n, hence there would be just 1 \n between the note and the signature, instead of 2.

Also this code needs to be updated because there can be multiple signatures.

Totally agree, a line with just \n separates the note and signatures. Plus Rekor also does it that way.
Plus multiple signatures.

Fixed in abfefdd.

flavio · 2025-11-26T16:18:46Z

src/rekor/models/checkpoint.rs

+
+/// The metadata that is contained in a checkpoint.
+#[derive(Debug, PartialEq, Clone, Eq)]
+pub struct CheckpointNote {


This is what the Go implementation calls Checkpoint, isn't it?

If that's the case, I would prefer to keep the same naming convention as the Go code. That makes easier to look at the Go codebase to understand what needs to be done inside of our Rust implementation

flavio · 2025-11-26T16:30:42Z

src/rekor/models/checkpoint.rs

+/// The `note` field stores this data,
+/// and its authenticity can be verified with the data in `signature`.
+#[derive(Debug, PartialEq, Clone, Eq)]
+pub struct Checkpoint {


This is what the Go implementation calls SignedCheckpoint.

This is evident when looking at the code that unmarshalls the go SignedNote (which is embedded into the Go SignedCheckpoint); that's the same logic used by the Rust Checkpoint.decode.

I find this discrepancy between the Go types and the Rust types super confusing. It makes comparing the Go implementation with ours harder.

I would stick with the Go naming

flavio · 2025-11-26T16:48:53Z

src/rekor/models/checkpoint.rs

+    fn encode(&self) -> String {
+        let sig_b64 =
+            BASE64_STANDARD.encode([self.key_fingerprint.as_slice(), self.raw.as_slice()].concat());
+        format!("— {} {sig_b64}\n", self.name)


replace the unicode char with its escape code \u2014

Done in 6ab967d.

flavio · 2025-11-26T16:59:01Z

src/rekor/models/checkpoint.rs

+            self.origin, self.size
+        )
+    }
+    fn unmarshal(s: &str) -> Result<Self, ParseCheckpointError> {


I would copy-paste this documentation and add that link too.

Found the source, https://github.com/transparency-dev/formats/blob/main/log/README.md, will use that throughout in addtion to this.

Done as part of bc19a18.

flavio · 2025-11-26T16:59:41Z

src/rekor/models/checkpoint.rs

+        )
+    }
+    fn unmarshal(s: &str) -> Result<Self, ParseCheckpointError> {
+        // refer to: https://github.com/sigstore/rekor/blob/d702f84e6b8b127662c5e717ee550de1242a6aec/pkg/util/checkpoint.go


nit, this link is too generic, you still have to go spelunking into the file to find what we're talking about. I would remove it (see previous comment)

Done in c915227.

flavio · 2025-11-26T17:07:16Z

src/rekor/models/checkpoint.rs

+        // refer to: https://github.com/sigstore/rekor/blob/d702f84e6b8b127662c5e717ee550de1242a6aec/pkg/util/checkpoint.go
+        // note is separated by new lines
+        let split_note = s.split('\n').collect::<Vec<_>>();
+        let [origin, size, hash_b64, other_content @ ..] = split_note.as_slice() else {


We need to raise an error if origin is empty: see the go implementation

Done in b6af9ca.

flavio · 2025-11-26T17:11:28Z

src/rekor/models/checkpoint.rs

+            .map_err(|_| DecodeError("failed to decode signature".to_string()))?;
+
+        // first four bytes of signature are fingerprint of key
+        let (key_fingerprint, sig) = sig.split_at(4);


Note split_at is also used elsewhere, please replace it with split_at_checked

flavio · 2025-11-26T17:17:52Z

src/rekor/models/consistency_proof.rs

+        let proof_hashes = self
+            .hashes
+            .iter()
+            .map(hex_to_hash_output)


Why are consistency proofs formatted as newline-separated hex strings? The tlog API seems to prefer newline-separated base64

Let's use base64

Also a nit: I think this low-level struct should carry bytestrings, not Strings. The conversion should happen somewhere higher up

True, I think there are other places where we should do this optimization. It would be nice to have this done as part of this PR, but I don't consider that as a blocker.

I think we should also investigate the usage of the bytes crate a bit

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

vembacher · 2025-11-29T10:48:03Z

Hello everyone, thanks for keeping this PR alive!

@vembacher: would you be ok with trying a rebase and correct DCO of this PR?
If not, I will take care of it by just fixing the conflicts, but potentially by opening a new PR with your changes already rebased.

Can I still help with this? I tried to run the rebase+signoff command but it made go through a lot of conflicts. I haven't kept up with the development of the crate so I did not feel confident to merge these correctly and from my understanding I would have to merge them manually. Is this correct?

I tried to get an overview of the current state of the PR, but I'm not sure if I missed something. But let me know if there is anything else I can assist you with in this PR or in the corresponding PR for the fork.

I will try my best to be assistive, but I unfortunately only have limited time to spend on this. But I will do my best to be responsive.

Ping: @viccuad @flavio @wolfv

tnytown mentioned this pull request Feb 14, 2024

Support for inclusion/consistency proofs and checkpoint/STH verification. #283

Open

gaetanww mentioned this pull request Mar 18, 2024

Better docs on how to verify signedEntryTimestamp sigstore/rekor#1943

Open

vembacher added 6 commits March 20, 2024 10:30

Added implementations for Merkle proofs.

0d3fc02

Relates to: sigstore#283 Signed-off-by: Victor Embacher <victor@embacher.xyz>

Added merkle proof examples, fixed some bugs, reduced repetition and …

7dd4224

…added some functionality. Relates to: sigstore#283 Signed-off-by: Victor Embacher <victor@embacher.xyz>

consolidated methods

73dd6e8

Signed-off-by: Victor Embacher <victor@embacher.xyz>

Added doctests to LogInfo and LogEntry merkle proof verification func…

d936abd

…tions. Signed-off-by: Victor Embacher <victor@embacher.xyz>

Rebased to main.

6d51377

Signed-off-by: Victor Embacher <victor@embacher.xyz>

Refactored to use a single library for JSON canonicalization.

e45c952

Signed-off-by: Victor Embacher <victor@embacher.xyz>

vembacher force-pushed the feature/merkle-proofs branch from acbcb91 to e45c952 Compare March 20, 2024 11:05

tnytown mentioned this pull request Apr 8, 2024

JSON canonicalization uses multiple libraries. #339

Open

changed usize to u64 for compatibility

4398466

Signed-off-by: Victor Embacher <victor@embacher.xyz>

viccuad and others added 2 commits November 18, 2025 17:06

docs: Add comments

f1cd7b7

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

chore: Fix comment on tests

df26379

Signed-off-by: Víctor Cuadrado Juan <2196685+viccuad@users.noreply.github.com>

viccuad previously approved these changes Nov 18, 2025

View reviewed changes

viccuad dismissed their stale review via bfac306 November 19, 2025 12:28

viccuad force-pushed the feature/merkle-proofs branch from bfac306 to df26379 Compare November 19, 2025 12:42

viccuad added 6 commits November 19, 2025 14:04

Merge branch 'main' into feature/merkle-proofs

3170357

Conflicts: Cargo.toml src/cosign/bundle.rs src/cosign/signature_layers.rs src/lib.rs src/registry/oci_caching_client.rs src/trust/mod.rs Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

chore: Cargo fmt

52734e5

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

deps: Reintroduce hex-literal

45ea819

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

chore: Fix clippy errors

5108a1d

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

tests: Don't run log_entry example

1b023d4

Needs unimplemented DSSE model. Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

build: Gate Merkle code under features

147cf7d

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

viccuad mentioned this pull request Nov 21, 2025

feat: add merkle tree test suite #527

Open

flavio reviewed Nov 26, 2025

View reviewed changes

viccuad mentioned this pull request Nov 26, 2025

full v0.3 bundle support #518

Closed

flavio requested changes Nov 26, 2025

View reviewed changes

viccuad added 5 commits November 27, 2025 11:36

refactor: Use split_at_checked()

61a2158

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

refactor: Use em dash unicode escape code in source

6ab967d

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

fix: Ensure signature line starts with em dash

5f29463

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

fix: Ensure signed envelope is correctly encoded with empty line

abfefdd

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

docs: Add encoding formats of envelope and signatures

bc19a18

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

viccuad force-pushed the feature/merkle-proofs branch from 771872c to 450189d Compare November 28, 2025 15:17

viccuad added 3 commits November 28, 2025 17:30

fix: Checkpoint can have several signatures

f68128d

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

fix: Check origin when unmarshalling note

b6af9ca

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

docs: Document CheckpointNote marshal() & unmarshal()

c915227

Signed-off-by: Víctor Cuadrado Juan <vcuadradojuan@suse.de>

viccuad force-pushed the feature/merkle-proofs branch from 0db8581 to c915227 Compare November 28, 2025 16:31

Merkle tree proof implementation #285

Are you sure you want to change the base?

Merkle tree proof implementation #285

Uh oh!

Conversation

vembacher commented Jul 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Release Note

Documentation

Todos:

Uh oh!

lukehinds commented Jul 20, 2023

Uh oh!

vembacher commented Jul 21, 2023

Uh oh!

flavio commented Sep 7, 2023

Uh oh!

vembacher commented Sep 19, 2023

Uh oh!

gaetanww commented Feb 14, 2024

Problem

Underlying problem

To fix

To reproduce

Uh oh!

tnytown commented Feb 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gaetanww commented Feb 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vembacher commented Feb 16, 2024

Uh oh!

gaetanww commented Feb 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vembacher commented Feb 16, 2024

Uh oh!

vembacher commented Feb 28, 2024

Uh oh!

gaetanww commented Mar 18, 2024

Uh oh!

vembacher commented Mar 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gaetanww commented Mar 18, 2024

Uh oh!

exFalso commented Jun 6, 2024

Uh oh!

tannaurus commented Aug 6, 2024

Uh oh!

loosebazooka commented Aug 13, 2024

Uh oh!

vembacher commented Aug 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loosebazooka commented Aug 20, 2024

Uh oh!

viccuad left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

exFalso commented Nov 21, 2025

Uh oh!

viccuad commented Nov 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

vembacher commented Jul 19, 2023 •

edited

Loading

tnytown commented Feb 16, 2024 •

edited

Loading

gaetanww commented Feb 16, 2024 •

edited

Loading

gaetanww commented Feb 16, 2024 •

edited

Loading

vembacher commented Mar 18, 2024 •

edited

Loading

vembacher commented Aug 19, 2024 •

edited

Loading

viccuad left a comment •

edited

Loading

viccuad Nov 28, 2025 •

edited

Loading

viccuad Nov 27, 2025 •

edited

Loading