Skip to content

Conversation

ok-nick
Copy link
Contributor

@ok-nick ok-nick commented Sep 24, 2025

This PR exposes our settings structs to the public API and adds json schemas to them for better compatibility with our bindings.

For reviewers:

  • What fields do we want exposed and what fields do we not want exposed?
  • Do we want to move around any fields?

@ok-nick ok-nick marked this pull request as ready for review September 25, 2025 18:13
Copy link

codspeed-hq bot commented Sep 25, 2025

CodSpeed Performance Report

Merging #1447 will not alter performance

Comparing ok-nick/pub-settings (9d80172) with main (2ffde3d)

Summary

✅ 16 untouched
⏩ 2 skipped1

Footnotes

  1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

/// <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,
Copy link
Contributor Author

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.

Copy link
Collaborator

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?

Copy link
Contributor Author

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).

Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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).

@ok-nick ok-nick force-pushed the ok-nick/pub-settings branch from 9faaa21 to 3cfa107 Compare September 29, 2025 20:23
@ok-nick ok-nick requested a review from gpeacock September 29, 2025 20:30
// 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))]
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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))]
Copy link
Collaborator

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,
Copy link
Collaborator

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,
Copy link
Collaborator

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>

Copy link
Contributor Author

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.
Copy link
Collaborator

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

Copy link
Contributor Author

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,
Copy link
Collaborator

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.

Copy link
Contributor Author

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,
Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants