fix: Limit the maximum number of assertions allowed for C2PA Manifest

[ssanthosh]

Changes in this pull request

Security Fix: Unbounded Assertion Count Allows Resource Exhaustion

Issue

No limit exists on the number of assertions that can be added to a manifest across three distinct code paths:

1. Builder::add_assertion / add_assertion_json (builder.rs) — the public API for constructing manifests programmatically.
2. Claim::add_assertion (claim.rs) — the lower-level API callable directly, bypassing Builder.
3. Store::from_jumbf_impl (store.rs) — the parsing path that processes assertions from untrusted, existing C2PA files.

An attacker can exploit paths 1 and 2 by constructing a manifest with an arbitrarily large number of assertions, and path 3 by supplying a crafted C2PA file with excessive assertions. All three cause uncontrolled memory and CPU consumption — a DoS vector for any application that creates or reads C2PA content.

---

Fix

New error variant (sdk/src/error.rs)

TooManyAssertions { max: usize }

Returned by all three enforcement points when the configured limit is exceeded.

New settings fields

• BuilderSettings.max_assertions: usize (sdk/src/settings/builder.rs) — default 50. Controls assertion creation via Builder and Claim.
• Verify.max_assertions: usize (sdk/src/settings/mod.rs) — default 50. Controls assertion parsing from untrusted files. Kept separate from builder.max_assertions so operators can tune creation and parsing limits independently.

Limit enforcement

File	Where	Reads
sdk/src/builder.rs	add_assertion, add_assertion_json	context.settings().builder.max_assertions
sdk/src/claim.rs	add_assertion_impl	get_thread_local_settings().builder.max_assertions
sdk/src/store.rs	from_jumbf_impl, before the assertion parsing loop	get_thread_local_settings().verify.max_assertions

Each point returns Err(TooManyAssertions { max }) before processing begins when the count meets or exceeds the limit.

---

Tests

builder.rs — test_add_assertion_limit

• Adds 50 assertions (default limit) — all succeed.
• Verifies the 51st returns TooManyAssertions { max: 50 }.
• Configurable limit: max_assertions: 2 via settings; verifies the 3rd is rejected.

claim.rs — test_add_assertion_default_limit_in_claim

• No settings manipulation; uses the default limit of 50.
• Adds 50 assertions — all succeed; 51st returns TooManyAssertions { max: 50 }.

claim.rs — test_add_assertion_limit_in_claim

• Lowers builder.max_assertions to 2 via thread-local settings.
• Adds 2 assertions — succeed; 3rd returns TooManyAssertions { max: 2 }.

store.rs — test_verify_default_assertion_limit_in_store

• Raises builder limit to 60 to create a manifest with 51 user assertions (signing adds further assertions).
• Restores builder limit; parses with the default verify.max_assertions (50) untouched.
• Verifies parse returns TooManyAssertions { max: 50 }.

store.rs — test_verify_assertion_limit_in_store

• Creates a manifest with 2 assertions; lowers verify.max_assertions to 1.
• Verifies parse returns TooManyAssertions { max: 1 }.

---

Checklist

• This PR represents a single feature, fix, or change.
• All applicable changes have been documented.
• Any TO DO items (or similar) have been entered as GitHub issues and the link to that issue has been included in a comment.

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks
⏩ 2 skipped benchmarks¹

---

_{Comparing ssanthosh/vulnerability_fixes_unbounded_assertions (264794a) with main (8efe78c)}

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

[tmathern]

Some APIs used are deprecated - local thread settings were replaced by settings on context. So some checks need to be weaved through differently.

[tmathern]

Why 50?

[tmathern]

Optional: If doing twice exactly the same check, maybe it could be refactored?

[tmathern]

I prefer all exports on top at the test suite

[gpeacock]

or at the top of the test module in this case

[tmathern]

This should be another test, test_add_assertion_limit_is_configurable

[tmathern]

I get the reason for this is that there is no context here or whatsoever to read the setting. But thread_local settings are another settings API that is deprecated. This likely needs to be weaved through differently.

[gpeacock]

If we are using a setting it should only be one from the context. Perhaps the answer is we just set a large fixed constant for this. If we really need to configure it in claim, then we may want to consider adding a way to set a max assertions value in claim from the current settings. But I think a constant may be fine. The other approach is to add context or settings to Claim but that feels like overkill for this.

[tmathern]

I get the reason for this is that there is no context here or whatsoever to read the setting. But thread_local settings are another settings API that is deprecated. This likely needs to be weaved through differently.

[gpeacock]

or at the top of the test module in this case

[gpeacock]

If we are using a setting it should only be one from the context. Perhaps the answer is we just set a large fixed constant for this. If we really need to configure it in claim, then we may want to consider adding a way to set a max assertions value in claim from the current settings. But I think a constant may be fine. The other approach is to add context or settings to Claim but that feels like overkill for this.