feat: Add cr_json() and cr_json_value() to Reader; remove separate CrJsonReader#1919
feat: Add cr_json() and cr_json_value() to Reader; remove separate CrJsonReader#1919
cr_json() and cr_json_value() to Reader; remove separate CrJsonReader#1919Conversation
…d certificate information. Updated schema to require manifests and jsonGenerator fields, and modified CrJsonReader to build and include jsonGenerator in the output. Improved claim signature handling to incorporate certificate details and timestamp information.
lrosenthol
left a comment
There was a problem hiding this comment.
A bit confused since I don't see changes to Reader, but still see CrJsonReader...
lrosenthol
left a comment
There was a problem hiding this comment.
Ah, I see what you. You moved all the crJSON code inot a new file with two new exported methods that then callable from the current Reader.
Fine with me.
This is to not introduce the new class that needs to be bound to other langs?
lrosenthol
left a comment
There was a problem hiding this comment.
Doesn't build
Compiling c2pa v0.77.0 (/Users/lrosenth/Development/c2pa-rs/sdk)
error[E0432]: unresolved import `sigtst::timestamp_token_bytes_from_sign1`
--> sdk/src/crypto/cose/mod.rs:50:5
|
50 | timestamp_token_bytes_from_sign1, timestamptoken_from_timestamprsp, validate_cose_tst_info,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `timestamp_token_bytes_from_sign1` in `crypto::cose::sigtst`
error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
--> sdk/src/crjson.rs:526:28
|
526 | if let Some(token_bytes) = timestamp_token_bytes_from_sign1(&sign1) {
| ^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `[u8]`
note: required by a bound in `std::prelude::v1::Some`
--> /Users/lrosenth/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/option.rs:600:17
|
600 | pub enum Option<T> {
| ^ required by this bound in `std::prelude::v1::Some`
...
608 | Some(#[stable(feature = "rust1", since = "1.0.0")] T),
| ---- required by a bound in this tuple variant
Some errors have detailed explanations: E0277, E0432.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `c2pa` (lib) due to 2 previous errors
|
It also appears that you took an older version of my code - as this has the old validation stuff, and needs my newer one. |
- Renamed "validationResults" to "validationInfo" in the schema to better reflect its purpose. - Enhanced the validationInfo to include a summary of validation information and validation time. - Updated the CrJsonExporter to build and include validationInfo in the output. - Modified the validationResults structure to clarify the distinction between document-level and per-manifest validation results. - Added support for ingredient deltas in the manifest validation results. - Updated tests to ensure compliance with the new schema structure.
|
This is a request to merge into the crjson branch, but if you have a newer branch we could merge into that. |
|
@gpeacock do we need to down merge this to crJSON or can we just merge it right into main? I think we're good on this branch - I am ready to merge it to main if you are! |
cr_json() and cr_json_value() to Reader; remove separate CrJsonReader
- Removed the document-level `validationInfo` in favor of per-manifest `validationResults`. - Introduced `manifestValidationResults` to encapsulate validation status codes and validation time for each manifest. - Updated `CrJsonExporter` to build validation results per manifest, ensuring each manifest's validation status is accurately represented. - Adjusted tests to reflect the new schema structure and validation results handling.
…ompliance tests - Rewrite crjson.rs using typed serde::Serialize structs (CrJsonClaim, CrJsonManifest, CrJsonSignature, etc.) for explicit schema compliance - Eliminate Manifest dependency; drive output directly from Store/Claim APIs - Add Reader::crjson() / crjson_checked() methods - Add --crjson flag to c2patool (conflicts with --detailed) - Add jsonschema dev-dependency (default-features = false for WASM compat) and rewrite schema_compliance tests to validate against the crJSON spec - Consolidate hash_assertions tests; delete redundant hash_encoding.rs - Revert validation_results.rs regression from commit 26fa080
|
I should have one more set of changes to make based on latest feedback... |
- Removed the `date` field from the `jsonGenerator` object in the crJSON schema. - Added `specVersion` to the validation results, ensuring it follows the SemVer format. - Updated the `validationTime` field to be required in the validation results. - Adjusted the `CrJsonExporter` to reflect these schema changes, including updates to the handling of validation results and hash encoding. - Modified tests to ensure compliance with the new schema, including checks for the `b64'` prefix in hash fields.
…rs into gpeacock/cr_json_tests
Merging this PR will not alter performance
Comparing Footnotes
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1919 +/- ##
==========================================
+ Coverage 76.50% 76.57% +0.07%
==========================================
Files 172 173 +1
Lines 41142 41671 +529
==========================================
+ Hits 31475 31909 +434
- Misses 9667 9762 +95 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…ndling Change crjson module from pub to pub(crate) (internal implementation detail) Remove manual hash/alg preservation from resource_store.rs; use add_with instead Move crJSON-schema.json from cli/schemas/ to sdk/tests/fixtures/schemas/ and update the reference Add CLI integration test for --crjson flag output Add check-format, check-docs, and clippy as prerequisites to test-sdk Makefile target Minor code formatting fixes (rustfmt-style rewraps across crjson.rs, hash_assertions.rs, schema_compliance.rs)
scouten-adobe
left a comment
There was a problem hiding this comment.
No blockers, but a couple of things to please consider.
This avoids a requirement for a separate Reader and porting that to other languages.
Another option would be to add a setting to default to crJson format, in which case there are no new language porting requirements.