formulation environmentVars as system-independent key-value

[jkowalleck]

• environmentVars
  • no longer arbitrary strings, nor wrong documented sets or objects.
  • now, they are system-independent key-value,
• fixes revisit environmentVar definitions #249
• fixes Please do not reuse propertyType for "environmentVar " #248
• fixes environmentVar could use a "unique" constraints #247

looks good in the docs:

[stevespringett]

RFC period ends on 6 October

[jaooli-cyber]

Thank you for opening this RFC. I tested the proposed change with a fully synthetic, reproducible fixture set against these exact revisions:

• 2.0-dev base: a1c8aeb2e4e6a72851fd937f210e9b5add1cf514
• PR formulation environmentVars as system-independent key-value #1088 head: 0ebfa3951e5cf0976e16debcf14c0ef8687fb4ef

The corpus contains 12 synthetic CycloneDX 2.0 formulation documents and 36 registered checks. All checks pass against the expected schema and migration matrix.

Observed schema boundary:

• all six legacy array-shaped cases are valid against the base and invalid against the PR schema;
• the three valid candidate map cases are invalid against the base and valid against the PR schema;
• nested-object, numeric and boolean map values are invalid against both pinned schemas.

Conservative migration results:

• 3 EQUIVALENT_NORMALIZATION;
• 6 UNVERIFIABLE without an external policy choice;
• 3 NOT_APPLICABLE invalid source shapes.

The main non-lossless or policy-dependent cases are arbitrary shell-like strings, repeated legacy names, and migration of candidate null values back to the legacy representation. One additional observation is that both revisions accept an empty variable name in their respective representations: [{"name":"","value":""}] in the base and {"":""} in the candidate. If the proposed model is intended to reject empty environment-variable names, an explicit non-empty key constraint may be needed.

The complete fixture set, evaluator, expected results, JSON/CSV/JUnit outputs, mutation control and CI reproduction are public here:

https://github.com/jaooli-cyber/cyclonedx-environmentvars-migration-fixtures

Successful clean CI reproduction:

https://github.com/jaooli-cyber/cyclonedx-environmentvars-migration-fixtures/actions/runs/34274307699

These results describe only the two pinned draft revisions. They do not take a position on acceptance of the RFC and are not a conformance statement about a released CycloneDX 2.0 specification. I would be happy to adapt the fixtures if another format would be more useful for the specification test suite.

[jkowalleck]

Thanks for the review

If the proposed model is intended to reject empty environment-variable names, an explicit non-empty key constraint may be needed.

There shall be no constraints on the name of an env var; any string is accepted.
I acknowledge that some systems may have constraints on a name, like "must start with a letter" or "must not be empty", while other systems don't have these constraints.
(while your specific shell have some constraints, your OS might bot not. test on a arbitrary linux: env '=empty-name' '0trust=starts-with-number' python -c 'import os;print(repr(os.environ))' clearly printing and env var with a number as first character, or even an empty name.

PS: I'll add a comment note to the JSON schema to make this clear

[jaooli-cyber]

Understood, thank you for clarifying. We will treat the empty-string key as valid at the CycloneDX model level and distinguish it from platform-specific executability constraints in our fidelity tests.

[jkowalleck]

updated the description/docs/examples to reflect the remarks regarding no constraints on env var name

[jaooli-cyber]

Thank you for clarifying this and for updating the schema description and examples. This resolves the ambiguity for our fixtures. We will treat empty and non-alphabetic names as valid at the CycloneDX model level, while keeping platform-specific executability as a separate interoperability dimension.