feat: implement validation test 6.2.31 for hardware and software path… by georgbramm · Pull Request #696 · csaf-rs/csaf

georgbramm · 2026-06-23T11:25:41Z

Implemented the mandatory CSAF Test 6.2.31 (Hardware and Software) validation logic to detect invalid mixtures of hardware and software products within the product tree.

Changes

Added src/validations/test_6_2_31.rs:
Aggregated all valid target product identifiers from product_tree.get_product_paths() by extracting the beginning references, full product IDs, and any relationship references via .get_subpath_product_references().
Utilized the framework's native visit_all_products_generic visitor pattern to recursively traverse all products across nested branches without manual recursion loops.
Verified if a product defines serial_numbers or model_numbers via the ProductIdentificationHelperTrait getters (.get_serial_numbers() / .get_model_numbers()).
Enforced that an error is generated if a hardware identifier lacks a corresponding structural product path.
Updated src/validations/mod.rs: Registered the new validation module into the validation pipeline execution.

Verification
Ran cargo test to verify compliance. All underlying framework validation test cases (case_01 through case_13) pass successfully.

…s, fixes issue csaf-rs#317

peinjoh

Hey there, thank you for your contribution! Here are some prelimary comments, I'll take a thourogh look later today and get back to you 👍

peinjoh · 2026-06-23T13:19:09Z

Also: Please wire up the tests to the application by commenting in the validations.rs line 👍

peinjoh · 2026-06-23T14:18:42Z

+    // 1. Gather all string references from the product paths cleanly
+    let mut valid_path_references: Vec<&str> = Vec::new();
+    let paths = product_tree.get_product_paths();
+


Two points here: As we only need to check for presence in the vec later, can this be deduplicated (with the included perf improvement) by using a HashSet?

I thought we have a utility function for this already. If not, extracting this as a utility function might be a good idea.

We have get_relationships_product_references already, but here the product_full_name are also included, which is, i think, not intended (see my comment).

peinjoh · 2026-06-23T14:24:49Z

+
+    #[test]
+    fn test_test_6_2_31() {
+        let case_01_failing_example_1 = Err(vec![generate_hardware_software_mix_error("CSAFPID-908070601")]);


I would argue that the test coverage can be improved here. There is currently no coverage of the model_numbers codepath, as the existing tests only concern serial_numbers. Similarly, there is no test products for serial_numbers and model_numbers being present at the same time (which is kind of trivial), and no test for what happens when there is no product_tree. We usually create a seperate issue for test coverage improvement, so this is not something you need to implement, but feel free to collect your thoughs on this on link them here 👍

Also: Test coverage could be extended to cover files that should produce multiple 6.2.31 warnings, i.e. with multiple offending products.

tziemek

Please also update the README and validation.rs file(-s).

tziemek · 2026-06-23T15:21:16Z

+    for path in paths {
+        let beg_ref = path.get_beginning_product_reference();
+        valid_path_references.push(beg_ref);
+


A full_product_name in a product_path with the required product_identification_helpers would pass as valid here, despite being not referenced in another product_path. Please clarify if this is as intended, otherwise remove these from the valid paths so they are reported.
Also, please add a supplementary test to cover this.

georgbramm · 2026-06-24T12:54:12Z

thanks for your valuable feedback, i will try to incorporate the requested changes by next week, as i am currently on a business trip

…cluded test in csaf2_1/validation.rs

georgbramm · 2026-07-03T12:38:01Z

i pushed a fix that hopefully resolves your requested changes

… by being defined inline as a full product node

…rences with get_relationships_product_references.

tziemek · 2026-07-06T15:14:12Z

Please add some supplementary test cases for everything that was unclear/discussed in this PR.

georgbramm · 2026-07-07T09:35:03Z

Last commit introduced a dedicated suite of supplementary test fixtures to resolve all edge-case validation behavior requested during the code review for Rule 6.2.31 (Hardware/Software Mix). These test scenarios are explicitly organized within a dedicated, manual test function (test_test_6_2_31_edge_cases). Isolating these structural, complex data matrix setups avoids interference with the rigid schema formatting assumptions used by the pre-generated test runner framework.

Rule 6.2.31 Supplementary Test Cases
Missing Product Tree Context (Case 01): Verifies that advisories completely omitting the optional product_tree structure return an Ok status rather than triggering runtime panics or structural validation failures.

Self-Validation Prevention (Case 02): Validates that standalone product entries containing conflicting hardware/software identifiers are caught, ensuring a product cannot implicitly clear its own requirement checks without valid external reference paths.

Model Numbers Code Path (Case 03): Adds targeted execution coverage specifically evaluating the model_numbers validation branch, ensuring full parity with existing serial_numbers tests.

Simultaneous Identifier Arrays (Case 04): Assures that the simultaneous presence of both serial_numbers and model_numbers inside a single configuration block is parsed and evaluated safely.

Multiple Offending Products (Case 05): Verifies full iteration and error accumulation mechanics by demonstrating that the validation engine captures all violation instances across multiple failing products instead of short-circuiting at the first failure.

tziemek · 2026-07-07T09:58:32Z

Last commit introduced a dedicated suite of supplementary test fixtures to resolve all edge-case validation behavior requested during the code review for Rule 6.2.31 (Hardware/Software Mix). These test scenarios are explicitly organized within a dedicated, manual test function (test_test_6_2_31_edge_cases). Isolating these structural, complex data matrix setups avoids interference with the rigid schema formatting assumptions used by the pre-generated test runner framework.

Rule 6.2.31 Supplementary Test Cases Missing Product Tree Context (Case 01): Verifies that advisories completely omitting the optional product_tree structure return an Ok status rather than triggering runtime panics or structural validation failures.

Self-Validation Prevention (Case 02): Validates that standalone product entries containing conflicting hardware/software identifiers are caught, ensuring a product cannot implicitly clear its own requirement checks without valid external reference paths.

Model Numbers Code Path (Case 03): Adds targeted execution coverage specifically evaluating the model_numbers validation branch, ensuring full parity with existing serial_numbers tests.

Simultaneous Identifier Arrays (Case 04): Assures that the simultaneous presence of both serial_numbers and model_numbers inside a single configuration block is parsed and evaluated safely.

Multiple Offending Products (Case 05): Verifies full iteration and error accumulation mechanics by demonstrating that the validation engine captures all violation instances across multiple failing products instead of short-circuiting at the first failure.

Case 01: looks fine, it's the obvious case
Case 02: generally looking fine, but the description says it prevents self validation. This is only possible within the product paths, not through full_product_names. Only the description is wrong, the case is still needed.
Case 03: looks fine, but then basically then same as case 02
Case 04: looks fine
Case 05: looks fine, the reasoning is confusing me. If you would add testfiles, this behavior is implicit as you would expect concrete results, not only an error.

Missing: case for a product declared within the product_path which has a serial or model number.

As mentioned in the other PR. Please add supplementary test files which can then be passed to the oasis tc.
If you need help with that, contact me.

georgbramm · 2026-07-08T07:14:08Z

I have updated the pull request to resolve the CSAF 6.2.31 validation issues, including the necessary JSON schema corrections and the requested supplementary test coverage. The updated test suite now includes five specific edge cases to ensure the validator correctly identifies products lacking a valid product path:

Case 1: Tests a standard nested product that fails due to a lack of branch category distinction.
Case 2: Tests a 'Model Only' product to verify failure when the branch lacks hardware/software context.
Case 3: Tests 'Simultaneous' identifiers (serial and model) to ensure ambiguity is flagged in versioned branches.
Case 4: Tests an 'Isolated Self-Val' component to confirm that even self-contained products require valid hierarchy anchoring.
Case 5: Acts as a catch-all to ensure consistent rule application for unanchored identifiers.

tziemek · 2026-07-08T08:31:35Z

+          {
+            "category": "product_version",
+            "name": "1.0",
+            "product": {
+              "product_id": "CSAFPID-908070601",
+              "name": "Product 1",
+              "product_identification_helper": { "serial_numbers": ["SN-1"] }
+            }
+          },


serial_numbers is already covered by the official test case 01.

tziemek · 2026-07-08T08:33:32Z

+          {
+            "category": "product_version",
+            "name": "4.0",
+            "product": {
+              "product_id": "CSAFPID-SELF-VAL",
+              "name": "Product 4",
+              "product_identification_helper": { "serial_numbers": ["SN-4"], "model_numbers": ["MOD-4"] }
+            }
+          },
+          {
+            "category": "product_version",
+            "name": "5.0",
+            "product": {
+              "product_id": "CSAFPID-FIFTH-CASE",
+              "name": "Product 5",
+              "product_identification_helper": { "serial_numbers": ["SN-5"], "model_numbers": ["MOD-5"] }
+            }
+          }


What is the difference between Product 3, 4 and 5?

tziemek · 2026-07-08T08:41:49Z

-    }
+        // S01: Edge cases
+        let mut s01 = vec![
+            // 1. Nested Product: Fails because it lacks a clear branch category distinction


What is meant by that? That there is product_name branch category missing? This doesn't concern this test.
Also it would be true for the other four cases listed here.

tziemek · 2026-07-08T08:42:38Z

+        let mut s01 = vec![
+            // 1. Nested Product: Fails because it lacks a clear branch category distinction
+            generate_hardware_software_mix_error("CSAFPID-908070601", "/product_tree/branches/0/branches/0/product"),
+            // 2. Model Only: Fails validation as branch lacks hardware/software context


The branch is not lacking the hardware/software context, a product path is missing.

tziemek · 2026-07-08T08:44:35Z

+            generate_hardware_software_mix_error("CSAFPID-908070601", "/product_tree/branches/0/branches/0/product"),
+            // 2. Model Only: Fails validation as branch lacks hardware/software context
+            generate_hardware_software_mix_error("CSAFPID-MODEL-ONLY", "/product_tree/branches/0/branches/1/product"),
+            // 3. Simultaneous: Fails as concurrent IDs create ambiguity in versioned branches


This description seems wrong. There is model and serialnumber present, which by itself is fine, but the product path is missing. There is no ambiguity.

tziemek · 2026-07-08T08:45:36Z

+            generate_hardware_software_mix_error("CSAFPID-MODEL-ONLY", "/product_tree/branches/0/branches/1/product"),
+            // 3. Simultaneous: Fails as concurrent IDs create ambiguity in versioned branches
+            generate_hardware_software_mix_error("CSAFPID-SIMULTANEOUS", "/product_tree/branches/0/branches/2/product"),
+            // 4. Isolated Self-Val: Fails as branch nesting fails to qualify as a valid leaf


This makes no sense, as it's the same data as case 03 and thus adds no additional value.

tziemek · 2026-07-08T08:45:41Z

+            generate_hardware_software_mix_error("CSAFPID-SIMULTANEOUS", "/product_tree/branches/0/branches/2/product"),
+            // 4. Isolated Self-Val: Fails as branch nesting fails to qualify as a valid leaf
+            generate_hardware_software_mix_error("CSAFPID-SELF-VAL", "/product_tree/branches/0/branches/3/product"),
+            // 5. Fifth Case: Fails due to unanchored product identification in hierarchy


This makes no sense, as it's the same data as case 03 and thus adds no additional value.

…ant test cases, and refine error messaging for missing product paths

georgbramm · 2026-07-08T09:35:24Z

Fixed: Synchronize publisher info and tracking ID, remove redundant test cases, and refine error messaging for missing product paths

feat: implement validation test 6.2.31 for hardware and software path…

496c8c2

…s, fixes issue csaf-rs#317

georgbramm requested a review from a team as a code owner June 23, 2026 11:25

fixed format

27804ec

peinjoh self-assigned this Jun 23, 2026

peinjoh reviewed Jun 23, 2026

View reviewed changes

Comment thread csaf-rs/src/validations/test_6_2_31.rs Outdated

Comment thread csaf-rs/src/validations/test_6_2_31.rs Outdated

peinjoh reviewed Jun 23, 2026

View reviewed changes

tziemek requested changes Jun 23, 2026

View reviewed changes

peinjoh mentioned this pull request Jun 23, 2026

feat: implement validation test 6.2.32 use of Same Product Identifica… #698

Open

Bramm added 2 commits July 3, 2026 14:35

fix: hopefully fixes all pull request comments; updated README.md; in…

e105289

…cluded test in csaf2_1/validation.rs

fixed: cargo fmt

05b8f41

tziemek reviewed Jul 6, 2026

View reviewed changes

Comment thread csaf-rs/src/validations/test_6_2_31.rs Outdated

fixed pr request. A product shouldn't implicitly validate itself just…

720f66c

… by being defined inline as a full product node

tziemek reviewed Jul 6, 2026

View reviewed changes

Comment thread csaf-rs/src/validations/test_6_2_31.rs Outdated

tziemek reviewed Jul 6, 2026

View reviewed changes

Comment thread README.md Outdated

Bramm added 3 commits July 6, 2026 16:21

resolve pr comments: updated README.md Exchanged get_all_product_refe…

c0ffbc7

…rences with get_relationships_product_references.

fixed test number in README.md

cce4719

added old 6.3.1 back again

802cb50

added 5 edge case tests in test_test_6_2_31_edge_cases

e43ce78

Fix 6.2.31: Add edge cases to product tree validation

5095280

tziemek requested changes Jul 8, 2026

View reviewed changes

Fix 6.2.31: Synchronize publisher info and tracking ID, remove redund…

cf26c41

…ant test cases, and refine error messaging for missing product paths

Uh oh!

Conversation

georgbramm commented Jun 23, 2026

Uh oh!

peinjoh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

peinjoh commented Jun 23, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tziemek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

georgbramm commented Jun 24, 2026

Uh oh!

georgbramm commented Jul 3, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tziemek commented Jul 6, 2026

Uh oh!

georgbramm commented Jul 7, 2026

Uh oh!

tziemek commented Jul 7, 2026

Uh oh!

georgbramm commented Jul 8, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

georgbramm commented Jul 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants