Context
The Workflow.public boolean field and the "public workflow → publicly discoverable" visibility model is being phased out in favor of RBAC-driven visibility (per-project visibility under each org).
Today, several authorization paths short-circuit on public-workflow membership:
pkg/biz/referrer.go: StoredReferrer.InPublicWorkflow field, hydrated in pkg/data/referrer.go::hydrateWorkflowsInfo
pkg/data/referrer.go::isReferrerVisible: short-circuits to true when the referrer is in any public workflow, bypassing RBAC
pkg/data/referrer.go: multiple workflow.Public(true) / workflow.Public(*public) predicates in doGet and the project-scoped attestation digest query
pkg/data/casmapping.go::154: return workflow.Public, nil
pkg/data/workflow.go::345: wfQuery.Where(workflow.Public(*opts.WorkflowPublic))
pkg/biz/workflowrun.go::727: authorization bypass when wfRun.Workflow.Public
- API filters:
--public / WorkflowPublic filter throughout the proto + service layers
Scope of removal
- Remove the public-workflow visibility short-circuit from
isReferrerVisible — visibility becomes RBAC-only.
- Stop using the
workflow.Public(...) ent predicate in new code; replace existing callsites with RBAC-derived predicates or remove the filter.
- Eventually drop the
public field from the Workflow schema (separate migration step — keep the column around during transition for rollback).
- Remove the proto-level public-workflow filter knobs that are no longer meaningful under RBAC.
Related
Surfaced while working on the referrer discovery project/version filter (#3155, PR #3158). That PR explicitly does not change public-workflow behavior — it adds RBAC-aware project filtering alongside the existing public short-circuit. Once this deprecation lands, the public branch in the referrer project-scope subquery can be removed.
Acceptance criteria
Context
The
Workflow.publicboolean field and the "public workflow → publicly discoverable" visibility model is being phased out in favor of RBAC-driven visibility (per-project visibility under each org).Today, several authorization paths short-circuit on public-workflow membership:
pkg/biz/referrer.go:StoredReferrer.InPublicWorkflowfield, hydrated inpkg/data/referrer.go::hydrateWorkflowsInfopkg/data/referrer.go::isReferrerVisible: short-circuits totruewhen the referrer is in any public workflow, bypassing RBACpkg/data/referrer.go: multipleworkflow.Public(true)/workflow.Public(*public)predicates indoGetand the project-scoped attestation digest querypkg/data/casmapping.go::154:return workflow.Public, nilpkg/data/workflow.go::345:wfQuery.Where(workflow.Public(*opts.WorkflowPublic))pkg/biz/workflowrun.go::727: authorization bypass whenwfRun.Workflow.Public--public/WorkflowPublicfilter throughout the proto + service layersScope of removal
isReferrerVisible— visibility becomes RBAC-only.workflow.Public(...)ent predicate in new code; replace existing callsites with RBAC-derived predicates or remove the filter.publicfield from theWorkflowschema (separate migration step — keep the column around during transition for rollback).Related
Surfaced while working on the referrer discovery project/version filter (#3155, PR #3158). That PR explicitly does not change public-workflow behavior — it adds RBAC-aware project filtering alongside the existing public short-circuit. Once this deprecation lands, the public branch in the referrer project-scope subquery can be removed.
Acceptance criteria
workflow.Publicpredicate removed from all production code paths (only schema + migration retain knowledge of the column)StoredReferrer.InPublicWorkflowremoved and dependent visibility logic updated to RBAC-only