fix: reject control characters in job names

[crowecawcaw]

What was the problem/requirement? (What/Why)

The spec bans control characters in job names, but this package allowed them.

Spec reference: https://github.com/OpenJobDescription/openjd-specifications/blob/mainline/wiki/2023-09-Template-Schemas.md#111-jobname

What was the solution? (How)

Add a regex to reject them.

What is the impact of this change?

How was this change tested?

Add unit tests. Also by running the conformance tests against the changes: OpenJobDescription/openjd-specifications#103

Was this change documented?

n/a

Is this a breaking change?

No

Does this change impact security?

No

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[mwiebe]

What's the difference between this and _standard_string_regex?

[crowecawcaw]

The model uses two regex engines: one is Rust's that's embedded in Pydantic and the other is Python's. They have slightly different syntax. _standard_string_regex is formatted for Pydantic/Rust's engine with \z and this regex is formatted for Python with \Z. This regex in this class is eventually evaluated here:

openjd-model-for-python/src/openjd/model/_format_strings/_dyn_constrained_str.py

Line 55 in 96651fa

if not re.match(cls._regex, value):

Here's another example of Python regexes in use in the model:

openjd-model-for-python/src/openjd/model/v2023_09/_model.py

Line 250 in 96651fa

_regex = f"(?-m:^[^{_Cc_characters}]+\\Z)"

Not sure there's a good reason for it. I'm guessing it is an outcome of upgrading from Pydantic v1 to v2.

[joel-wong-aws]

+1. From Kiro:

_standard_string_regex = rf"(?-m:^[^{_Cc_characters}]+\z)"

\\Z (uppercase Z): Matches at the end of the string OR just before a newline at the end

"hello\n" ✅ matches
"hello" ✅ matches

\z (lowercase z): Matches only at the absolute end of the string

"hello\n" ❌ does not match
"hello" ✅ matches

The lowercase \z seems to be the correct choice here.

[mwiebe]

I remember there being something different between \z and \Z between pydantic v2 and Python regexes, because pydantic v2 switched to using the Rust regex crate.

[crowecawcaw]

The \Z vs \z difference is intentional due to two different regex engines being in play:

• _standard_string_regex (used by JobName, StepName, EnvironmentName via pydantic StringConstraints) uses lowercase \z — this is correct because pydantic v2 validates these patterns via pydantic-core, which uses the Rust regex crate. In Rust regex, \z is the absolute end-of-string anchor. Ref

• JobTemplateName._regex (used by DynamicConstrainedStr._validate) uses uppercase \Z — this is correct because validation runs through Python's re.match(). In Python's re module, \Z matches only at the absolute end of the string (it does NOT match before a trailing newline, unlike $). Python doesn't support lowercase \z in versions before 3.14 — it throws re.PatternError: bad escape \z. Ref

So both are equivalent in behavior (absolute end-of-string), just spelled differently for their respective engines.

I've added additional tests to verify newlines are handled correctly.

[leongdl]

I think we should add a fuzz test suite to OpenJD and have broader testing. Maybe a good backlog item for the OpenJD team.

[crowecawcaw]

We actually have a new-ish fuzzer that uncovered a couple issues: https://github.com/OpenJobDescription/openjd-model-for-python/blob/mainline/test/openjd/model/test_fuzz.py

We could definitely extend it for better coverage. In this particular case, I don't think it would have helped because the problem was not that a regex was faulty, it's that the library was missing a validation.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud