Add v0.2 bundle tests#112
Conversation
bdehamer
force-pushed
the
bdehamer/dsse-bundle-verify
branch
from
b1da294 to
8025e0a
Compare
Signed-off-by: Brian DeHamer <bdehamer@github.com>
bdehamer
force-pushed
the
bdehamer/dsse-bundle-verify
branch
3 times, most recently
from
db8862a to
2d7481f
Compare
|
Thanks @bdehamer! |
woodruffw
left a comment
woodruffw
left a comment
There was a problem hiding this comment.
I did a quick pass, and LGTM! Tagging @tnytown for an additional review.
Just for xrefs: sigstore/sigstore-python#804 will add DSSE support to sigstore-python, once complete.
tnytown
left a comment
tnytown
left a comment
There was a problem hiding this comment.
All of these bundles were signed with a private Sigstore instance and must be verified using a custom
trusted_root.json.
This is sigstore/sigstore-python#821, right?
I didn't check the test assets, but the harness additions look good to me!
Yep, that's right. I'd like to get sigstore/sigstore-python#814 merged in and then move on that. |
| Test the happy path of verification for DSSE bundle w/ custom trust root | ||
| """ | ||
| materials: BundleMaterials | ||
| input_path, materials = make_materials_by_type("d.stmt.json", BundleMaterials) |
There was a problem hiding this comment.
I know I'm a bit late, but I don't think is quite right.
test/assets/d.stmt.json should be the artifact whose hash matches what's in the in-toto statement, not the in-toto statement itself.
sigstore-go says this test should fail, because the test/assets/d.stmt.good.sigstore DSSE payload says the hash of the artifact should be sha512:90f22..., and the hash of the current test/assets/d.stmt.json is sha512:9163d....
There was a problem hiding this comment.
I think you're right -- this is an unfortunate consequence of having sigstore-python be the only "acceptance" suite currently running 😅
Would you mind sending a PR for this? Otherwise I can poke at it when I have a free moment.
There was a problem hiding this comment.
Sure! See #114.
This might have uncovered another bug in test_verify_rejects_bad_tsa_timestamp, although I'm not sure yet if the bug is in sigstore-go or the conformance test!
sigstore/sigstore-conformance#112 includes confromance tests with a mock Sigstore where there are no Fulcio intermediate certificates. Signed-off-by: Zach Steindler <steiza@github.com>
* Support Fulcio certificate "chains" that just have a root sigstore/sigstore-conformance#112 includes confromance tests with a mock Sigstore where there are no Fulcio intermediate certificates. Signed-off-by: Zach Steindler <steiza@github.com> * Clarify leaf CT certificate Signed-off-by: Zach Steindler <steiza@github.com> --------- Signed-off-by: Zach Steindler <steiza@github.com>
It seems like this is the behavior that `test_verify_rejects_bad_tsa_timestamp` is assuming, that was added in sigstore/sigstore-conformance#112. Signed-off-by: Zach Steindler <steiza@github.com>
…cy (#42) `test_verify_rejects_bad_tsa_timestamp`, which was added in sigstore/sigstore-conformance#112, expects us reject bundles that have a bad TSA timestamp when the trust root has TSA information in it. --------- Signed-off-by: Zach Steindler <steiza@github.com>
5 participants
Adds a handful of new bundle verification tests to the suite:
All of these bundles were signed with a private Sigstore instance and must be verified using a custom
trusted_root.json.