-
Notifications
You must be signed in to change notification settings - Fork 99
feat: add settings structs to the public API #1447
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
base: main
Are you sure you want to change the base?
Conversation
CodSpeed Performance ReportMerging #1447 will not alter performanceComparing Summary
Footnotes
|
/// <div class="warning"> | ||
/// Verifying trust is REQUIRED by the C2PA spec. This option should only be used for development or testing. | ||
/// </div> | ||
pub verify_trust: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should have verify_c2pa_trust
and verify_cawg_trust
to be clear they are separate and also to clarify it doesn't encompass timestamp trust. I'll add to the docs that verify_timestamp_trust
should be used in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that if you configure the Trust settings, you probably want to use them. So why do we need a separate set of flags to enable them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We currently do have a separate set of flags to enable them, see Trust::verify_trust_list
(CAWG) and Verify::verify_trust
(C2PA).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but why? Trust lists are required by the spec, I guess disabling could be useful for debugging?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to hear @scouten-adobe input on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a separate Trust
structure (see https://github.com/contentauth/c2pa-rs/pull/1447/files/aee4a005f7ebabead90b13bb5f9afe92a177f40f#diff-40b334ea0cacc187a239b5763c0403155527f660c81e8e90462bc01a3c36bf0dR50) which already occurs twice, once for CAWG and once for C2PA.
I'd like to see us move as much of this configuration into that tree and then the question of which one you are enabling/disabling will be much more obvious (IMHO).
9faaa21
to
3cfa107
Compare
// TODO: all of these settings aren't implemented | ||
// Settings for core C2PA-RS functionality | ||
/// Settings to configure core features. | ||
#[cfg_attr(feature = "json_schema", derive(schemars::JsonSchema))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we keep core features config SDK-internal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the core settings in this PR are reasonable to expose to the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make sure we get Maurice's opinion on these
// TODO: all of these settings aren't implemented | ||
// Settings for core C2PA-RS functionality | ||
/// Settings to configure core features. | ||
#[cfg_attr(feature = "json_schema", derive(schemars::JsonSchema))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make sure we get Maurice's opinion on these
/// <div class="warning"> | ||
/// Verifying trust is REQUIRED by the C2PA spec. This option should only be used for development or testing. | ||
/// </div> | ||
pub verify_trust: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a separate Trust
structure (see https://github.com/contentauth/c2pa-rs/pull/1447/files/aee4a005f7ebabead90b13bb5f9afe92a177f40f#diff-40b334ea0cacc187a239b5763c0403155527f660c81e8e90462bc01a3c36bf0dR50) which already occurs twice, once for CAWG and once for C2PA.
I'd like to see us move as much of this configuration into that tree and then the question of which one you are enabling/disabling will be much more obvious (IMHO).
/// An image in WEBP format. | ||
WebP, | ||
/// An image in TIFF format. | ||
Tiff, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we support TIFF thumbnails>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's naturally supported by the image
crate although I have no objection to removing it.
#operating_system.name = "macOS" | ||
# Or if the name isn't specified, it can be inferred automatically. | ||
operating_system.infer = true | ||
# Or specify "auto" to infer the operating system automatically. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we fetching OCSP responses for every certificate as a default!
certificate_status_fetch = "all"
certificate_status_should_override = true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, that's interesting. @scouten-adobe any input on this?
/// Fetch OCSP for all manifests. | ||
All, | ||
/// Fetch OCSP for the active manifest only. | ||
Active, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this meant to be used in the settings file? Without an "off" choice then the presence of OCSPFetchScope will mean we are fetching responses. I do not thing fetching should ever default to on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
certificate_status_fetch
is defined as Option<OcspFetchScope>
that defaults to None
.
/// Whether to fetch the certificates OCSP status during validation. | ||
/// | ||
/// The default value is false. | ||
pub ocsp_fetch: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has nothing to do with Reader, the value determines whether we fetch OCSP during validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that's what I was trying to convey. The docs seem to match your description, which part seems unclear?
This PR exposes our settings structs to the public API and adds json schemas to them for better compatibility with our bindings.
For reviewers: