Skip to content

Conversation

@st3penta
Copy link
Contributor

Add semver version constraint checking for Tekton task rules, enabling allow/deny decisions based on task version ranges. Tasks can now be restricted to specific versions using constraints like

=2, <3, >3.1.0, <=v4.2.

The implementation includes a complete semver parser supporting major.minor.patch formats (with or without 'v' prefix) and comparison operators (>=, >, <=, <). Version constraints apply only to OCI bundle references with tagged versions.

Co-authored-by: Claude Code [email protected]

Ref: https://issues.redhat.com/browse/EC-1541

@codecov
Copy link

codecov bot commented Dec 17, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines Coverage Δ
policy/lib/tekton/trusted.rego 100.00% <100.00%> (ø)
policy/lib/tekton/trusted_test.rego 100.00% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@st3penta
Copy link
Contributor Author

These are currently standalone functions, actual integration depends on: #1595

_is_valid_semver(version)
parsed_version := _semver_parse(version)

# Version must match at least one constraint
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to understand this comment. Should it say "must match every constraint", since we have an every on the next line?

Or do we mean there must be at least one rule.versions, in which case should we do count(rule.versions) > 0 to make that explicit? Or does every behave that way implicitly, and the comment is to make that more clear?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, it should say "must match every constraint"

Copy link
Member

@simonbaird simonbaird left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming we don't have a good reason to re-implement semver compare. Would be interesting to see if the same tests pass.

# Compare two parsed semantic versions
# Takes two parsed version objects from _semver_parse
# Returns -1 if a < b, 0 if a == b, 1 if a > b
_semver_compare(a, b) := -1 if {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh...I looked for that and didn't find anything 🤦‍♂️

Comment on lines 317 to 321
# Extract version/tag from task reference
# For OCI bundles, this is the tagged_ref (e.g., "0.4" from "oci://registry.io/task:0.4")
# For git references, there's no version tag, so this function will return false
"tagged_ref" in object.keys(ref)
version := ref.tagged_ref
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this needs to be refactored. See: #1595 (review)

@st3penta st3penta marked this pull request as draft December 19, 2025 14:44
@github-actions github-actions bot added size: L and removed size: XL labels Dec 19, 2025
Add semver version constraint checking for Tekton task rules,
enabling allow/deny decisions based on task version ranges. Tasks
can now be restricted to specific versions using constraints like
>=2, <3, >3.1.0, <=v4.2.

The implementation includes a complete semver parser supporting
major.minor.patch formats (with or without 'v' prefix) and
comparison operators (>=, >, <=, <). Version constraints apply
only to OCI bundle references with tagged versions.

Co-authored-by: Claude Code <[email protected]>

Ref: https://issues.redhat.com/browse/EC-1541
@github-actions github-actions bot added size: XL and removed size: L labels Dec 19, 2025
@st3penta st3penta marked this pull request as ready for review December 19, 2025 16:59
@st3penta st3penta force-pushed the EC-1541 branch 2 times, most recently from f5bd693 to 71564b1 Compare December 19, 2025 17:14
@joejstuart
Copy link
Contributor

The schema has additionalProperties: true which is allowing the versions key, but maybe we should add it to the schema. It could help with validation.

@joejstuart
Copy link
Contributor

joejstuart commented Dec 19, 2025

Also, when I test it I get some errors. Cursor says it's from the oci:// prefix. Might need to strip that.

ERRO[0017] unable to resolve digest: Get "https://oci/v2/": dial tcp: lookup oci: no such host  action=resolveIfNeeded function=ec.oci.image_manifest input_ref="oci://quay.io/konflux-ci/tekton-catalog/task-buildah-remote:0.4"
ERRO[0017] unable to resolve digest: Get "https://oci/v2/": dial tcp: lookup oci: no such host  action=resolveIfNeeded function=ec.oci.image_manifest input_ref="oci://quay.io/konflux-ci/tekton-catalog/task-git-clone:0.1"
ERRO[0017] unable to resolve digest: Get "https://oci/v2/": dial tcp: lookup oci: no such host  action=resolveIfNeeded function=ec.oci.image_manifest input_ref="oci://quay.io/konflux-ci/tekton-catalog/task-buildah:0.4"

@st3penta
Copy link
Contributor Author

Also, when I test it I get some errors. Cursor says it's from the oci:// prefix. Might need to strip that.

I can't reproduce the error (i even added an acceptance test for that, see my last commit), can you clarify which tests are you running?

@st3penta st3penta requested a review from joejstuart December 22, 2025 16:07
@joejstuart
Copy link
Contributor

Also, when I test it I get some errors. Cursor says it's from the oci:// prefix. Might need to strip that.

I can't reproduce the error (i even added an acceptance test for that, see my last commit), can you clarify which tests are you running?

I'm just running the cli

ec validate image \
  --image quay.io/redhat-user-workloads/rhtap-contract-tenant/golden-container/golden-container@sha256:185f6c39e5544479863024565bb7e63c6f2f0547c3ab4ddf99ac9b5755075cc9 \
  --policy ./policy.yaml \
  -k pub.key \
  --ignore-rekor \
  --output text \
  --strict=false 

st3penta and others added 3 commits December 23, 2025 11:57
The version extracted from the task ref can't be relied upon, since it
is easily counterfeitable.

Instead, as per ADR decision (see attached link), we are going to
extract the version annotation from inside the task manifest, and use
that to evaluate the version constraints in the trusted task rules.

Ref: https://github.com/konflux-ci/architecture/blob/main/ADR/0054-task-versioning.md#mark-each-meaningful-change-with-a-version-update
This allows for a more exact validation, instead of relying on the
'additionalProperties' attribute
The acceptance test cases cover the case of both trusted tasks and
untrusted tasks.

The version constraints in the trusted_task_rules are difficult to test
at the moment, since they test the version annotation inside the
manifest, and NOT the version in the oci ref of a task.
Since no version annotations are currently present in any task manifest,
the constraints will always evaluate to false (for allow rules) or to
true (for deny rules).

Co-authored-by: Claude Code <[email protected]>
Copy link
Contributor

@joejstuart joejstuart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works great. The only issue is the performance. A normal Conforma run takes around 20 seconds for one image. With this it takes 60. I think we can merge this, but I'll create a story to handle the performance issue.

@st3penta st3penta merged commit 5f0159a into conforma:main Dec 23, 2025
7 checks passed
@st3penta st3penta deleted the EC-1541 branch December 23, 2025 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants