Repository navigation
Open
Labels
area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)Issues or PRs related to platform infrastructure (bundle, flux, talos, installer)kind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a bugpriority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next releaseMust be staffed and worked on either currently, or very soon, ideally in time for the next releasesecuritySecurity-related issues and featuresSecurity-related issues and featurestriage/acceptedIndicates an issue is ready to be actively worked onIndicates an issue is ready to be actively worked on
Description
Summary
Name checks on the server cover only exact PackageSource name, so two sources can end up on one artifact name and one of them gets built from the other's content.
- Server checks exact PackageSource name only.
collision.PackageSourceName(collision.go L87-L102) fails when PackageSource with same name exists and is not the tap's own. It is called fromcozypkg tapand from materializer (tapmaterializer_reconciler.go L144), nothing else is compared. - Reserved names exist only in
cozypkg validate.reservedNamePrefixesis{"cozystack.", "community."}(validate.go L123-L129), applied offline and skippable with--allow-reserved-names. Comment there says on-cluster check is the real boundary, but tap-labelled OCIRepository reaches materializer without CLI, and neither materializer nor Tap REST handler has reserved-name check. - Artifact name drops difference between
.and-.naming.ArtifactNamereplaces dots with dashes in all three segments (naming.go), so platform sourcecozystack.cert-managerand tapped sourcecozystack-cert-managerwith same variant and component give same ExternalArtifact namecozystack-cert-manager-<variant>-<component>. Checks 1 and 2 let it through, PackageSource names differ and dashed form is not reserved prefix. More generally mapping is not injective:acme.web/default/x,acme-web/default/xandacme/web-default/xall giveacme-web-default-x. Only artifact-name collision check is inside one PackageSource (validate.go L320-L363).
Impact
I expect source-watcher applies second source over the first without owner check, but I did not read that code or run it, so first step of the fix is to confirm it on a dev stand. Everything above is read in code, nothing reproduced on a cluster.
Suggested fix
- Reject PackageSource whose normalised artifact names equal another PackageSource's. Injective encoding (hash suffix, or separator that can't appear in names) would remove whole class, but it changes artifact names that ApplicationDefinitions already reference. Do the check where exact-name check already runs (materializer and Tap create), so it holds for labelled OCIRepository that never went through CLI.
- Enforce reserved names on server in same places and cover dashed form (
cozystack-). Decide in same change whethercommunity.stays reserved, prefix was dropped from tap flow in #3940 but CLI still lists it. - Extend artifact-name accounting in
validate.gobeyond one source, at least against platform's own PackageSources. - Remove duplicate of name construction in package_reconciler.go L280-L283 and call
naming.ArtifactName, the package's own comment says definition must live in one place. - Operator already refuses to apply platform PackageSource over tapped one (main.go L801-L812), artifact-name check is the other half of that guard.
Acceptance
- Tapped source named
cozystack-cert-manageris refused while platform shipscozystack.cert-managerwith matching variant and component. - Labelled OCIRepository created without CLI is refused for same reason.
- Unit tests in
collisionandnamingfor clashing and non-clashing case.
Reacted by dosubot
Metadata
Metadata
Assignees
Labels
area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)Issues or PRs related to platform infrastructure (bundle, flux, talos, installer)kind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a bugpriority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next releaseMust be staffed and worked on either currently, or very soon, ideally in time for the next releasesecuritySecurity-related issues and featuresSecurity-related issues and featurestriage/acceptedIndicates an issue is ready to be actively worked onIndicates an issue is ready to be actively worked on
Activity