harden: a handed-over tap Package can escalate to privileged on a later revision without re-confirmation #4358

Context

PR #4308 refuses privileged install components for an unconfirmed tap registration Package (one still carrying the apps.cozystack.io/marketplace-tap label) at the install site. cozypkg add --allow-privileged is the operator confirmation: it sheds the tap markers, turning the Package into a plain user Package, after which the Package reconciler installs its privileged components freely.

Gap

If a later artifact revision flips that already-confirmed variant (benign when the operator confirmed it) to privileged, the new privileged component installs without a fresh confirmation, because the Package no longer carries the tap markers. The operator approved the variant when it was benign, not when it became privileged.

This is a pre-existing property (a user-created Package on main today behaves the same); #4308 closes only the auto-registration escalation. This issue tracks the residual case for a handed-over tap Package.

Suggested fix

Record on the Package the set of privileged component names the operator approved (name-bound, matching the current --allow-privileged granularity) plus a durable "came from a tap" provenance marker kept after handover, and have the Package reconciler install a privileged component only when it is in the approved set: a default-deny allowlist rather than the current tap-label denylist. A privileged component introduced by a later revision is then refused with a condition until the operator re-approves.

Not a regression introduced by #4308 (flagged by Aleksei Sviridkin (@lexfrei) and CodeRabbit during its review).