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

Support verifying Sigstore bundles #478

Merged
merged 18 commits into from
Jan 31, 2023
Merged

Support verifying Sigstore bundles #478

merged 18 commits into from
Jan 31, 2023

Conversation

tetsuo-cpp
Copy link
Collaborator

No description provided.

Signed-off-by: Alex Cameron <asc@tetsuo.sh>
Signed-off-by: Alex Cameron <asc@tetsuo.sh>
Signed-off-by: Alex Cameron <asc@tetsuo.sh>
Signed-off-by: Alex Cameron <asc@tetsuo.sh>
Signed-off-by: Alex Cameron <asc@tetsuo.sh>
Signed-off-by: Alex Cameron <asc@tetsuo.sh>
Signed-off-by: Alex Cameron <asc@tetsuo.sh>
@@ -76,6 +76,13 @@ class LogEntry:
The base64-encoded Signed Entry Timestamp (SET) for this log entry.
"""

# NOTE: After Rekor bundles (provided by `--rekor-bundle`) are removed, this will no longer be
# necessary.
_from_rekor_bundle: bool
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't great, but we'll be able to remove it soon when we get rid of --rekor-bundle so I'm not too worried about it.

The only problem I see is that even though this field is marked as internal, you still need to provide a value for it if you construct one yourself. But I don't think users of the API have a good reason to be doing that anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also outputs a RuntimeWarning from Pydantic at runtime:

RuntimeWarning: fields may not start with an underscore, ignoring "_from_rekor_bundle"

Copy link
Member

@woodruffw woodruffw Jan 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think we can do a little better than this API (both the private field and the manual initialization). I'll look into it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, maybe we can just remove --rekor-bundle outright? We never "actually" stabilized it (we've always emitted a warning said that it's temporary and will be removed in an upcoming release), and we never integrated it into other tooling (like the GH Action) or other expectations (e.g. CPython doesn't list it).

Thoughts @di?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine with me!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! I'll just yank all of that out, then, and save us from even having to think about this 🙂

Copy link
Member

@di di left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM aside from the RuntimeWarning, we should find a workaround for that.

@woodruffw woodruffw added component:cli CLI components component:verification Core verification functionality labels Jan 30, 2023
Vestigial now that we have Sigstore bundle support.

Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Comment on lines 147 to 153
offline: bool
"""
Whether to do offline Rekor entry verification.

This is a slightly weaker verification verification mode, as it demonstrates
that an entry has been signed by the log but not necessarily included in it.
"""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flagging: I'm not super happy with this setting being here, since it's conceptually a verification option rather than a material.

The other possibility I can think of is a separate VerificationOptions model, but that might be overkill given that this is currently the only option we support. But maybe there will be more in the future?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I think it's ok.

If we go for a separate VerificationOptions model, we're never going to collapse that back into VerificationMaterials even if it remains as one option for a very long time because there's always going to be the possibility of more.

Copy link
Member

@woodruffw woodruffw Jan 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a good point. I think what I'll do is make it "private" like _rekor_entry so that it isn't part of our public API commitment. It'll still end up being stabilized as part of the methods on VerificationMaterials, but that'll at least avoid the need to change this model's public fields if we ever do decide to refactor it.

Signed-off-by: William Woodruff <william@trailofbits.com>
@woodruffw
Copy link
Member

@tetsuo-cpp I'll kick this back over to you, but to summarize the changes I've made:

  • I removed Rekor bundle support entirely, both in the internal APIs and in the CLI
  • I added VerificationMaterials.offline and VerificationMaterials.from_bundle(...), the latter being the expected API for converting a Sigstore bundle into its equivalent materials.
  • I fixed up the unit tests for my changes and added some new assets/updated the fixtures to reflect them.

I think this is in a pretty good state overall, but IMO we should bring the test coverage up a bit -- it'd be good to get some coverage for the new InvalidMaterials exception and its raise-sites.

Signed-off-by: Alex Cameron <asc@tetsuo.sh>
@tetsuo-cpp
Copy link
Collaborator Author

I think this is in a pretty good state overall, but IMO we should bring the test coverage up a bit -- it'd be good to get some coverage for the new InvalidMaterials exception and its raise-sites.

Done in dc1cb3b.

Comment on lines -217 to +207
"--require-rekor-offline",
"--offline",
action="store_true",
default=_boolify_env("SIGSTORE_REQUIRE_REKOR_OFFLINE"),
help="Require offline Rekor verification with a bundle; implied by --rekor-bundle",
default=_boolify_env("SIGSTORE_OFFLINE"),
help="Perform offline verification; requires a Sigstore bundle",
Copy link
Member

@woodruffw woodruffw Jan 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm now realizing that this is slightly misleading, since --offline implies "fully" offline, whereas we still do some network requests for TUF. I think we should keep this flag, though, and work on removing/suppressing those requests when the user requests offline verification.

Signed-off-by: William Woodruff <william@trailofbits.com>
Copy link
Member

@woodruffw woodruffw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! :shipit:

@woodruffw woodruffw merged commit fc4e9b3 into main Jan 31, 2023
@woodruffw woodruffw deleted the alex/verify-bundle branch January 31, 2023 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:cli CLI components component:verification Core verification functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants