You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Today, metadata signing services bind one key per service. The base SigningService.sign() signs with whatever key the service was created with, with no per-call override. Both metadata services inherit this unchanged: AsciiArmoredDetachedSigningService (pulpcore, RPM repomd.xml) and AptReleaseSigningService (pulp_deb, deb Release). Package signing already solved this — RpmPackageSigningService.sign() takes a pubkey_fingerprint and injects it as PULP_SIGNING_KEY_FINGERPRINT, so one service signs for many keys.
As a result, signing repositories' metadata with different keys requires a separate signing service per key. In containerized deployments each new key means a new add-signing-service registration (on-disk script, importable GPG key, full validate() run) — effectively a deployment change per key. This is the pain behind pulpcore #6733 and pulp/pulp_rpm#4052.
Describe the solution you'd like
Mirror the package-signing pattern on the shared base method so both metadata services benefit:
Add an optional pubkey_fingerprint=None kwarg to the base SigningService.sign() (and asign()). When set, it overrides PULP_SIGNING_KEY_FINGERPRINT; when unset, it falls back to the service's own key (today's behavior). AsciiArmoredDetachedSigningService and AptReleaseSigningService inherit this automatically, since neither overrides sign().
Plugins add a nullable metadata_signing_fingerprint on their repository models (parallel to package_signing_fingerprint) and forward it from the publish task.
A deployment then registers one generic metadata signing service per format at boot and selects the key per publish via the repository's fingerprint.
FWIW - this solution is backwards compatible: _env_variables already injects PULP_SIGNING_KEY_FINGERPRINT, so this only overrides a value already passed; the kwarg is optional and defaults to None (unlike RpmPackageSigningService.sign(), which made it mandatory); the repo field is nullable; and validate() is unchanged since it signs with no fingerprint.
Describe alternatives you've considered
A writable signing-service create/delete REST API (pulpcore Allow signing services to be managed via the API #6733). Still one service per key, still carries the on-disk-script + keyring + validate() side effects, and re-opens the arbitrary-script-path security concern that stalled that issue.
Invoking add-signing-service at runtime. Operationally fragile, couples callers to Pulp's pod internals, and produces a sprawl of per-key services.
Keeping the fingerprint purely in the plugin (as Add metadata_signing_fingerprint to repository pulp_rpm#4052 leaned). The repo field is inert unless the base sign() honors a per-call fingerprint — which is why this pulpcore change is the prerequisite.
Is your feature request related to a problem? Please describe.
Today, metadata signing services bind one key per service. The base
SigningService.sign()signs with whatever key the service was created with, with no per-call override. Both metadata services inherit this unchanged:AsciiArmoredDetachedSigningService(pulpcore, RPMrepomd.xml) andAptReleaseSigningService(pulp_deb, debRelease). Package signing already solved this —RpmPackageSigningService.sign()takes apubkey_fingerprintand injects it asPULP_SIGNING_KEY_FINGERPRINT, so one service signs for many keys.As a result, signing repositories' metadata with different keys requires a separate signing service per key. In containerized deployments each new key means a new
add-signing-serviceregistration (on-disk script, importable GPG key, fullvalidate()run) — effectively a deployment change per key. This is the pain behind pulpcore #6733 and pulp/pulp_rpm#4052.Describe the solution you'd like
Mirror the package-signing pattern on the shared base method so both metadata services benefit:
pubkey_fingerprint=Nonekwarg to the baseSigningService.sign()(andasign()). When set, it overridesPULP_SIGNING_KEY_FINGERPRINT; when unset, it falls back to the service's own key (today's behavior).AsciiArmoredDetachedSigningServiceandAptReleaseSigningServiceinherit this automatically, since neither overridessign().metadata_signing_fingerprinton their repository models (parallel topackage_signing_fingerprint) and forward it from the publish task.A deployment then registers one generic metadata signing service per format at boot and selects the key per publish via the repository's fingerprint.
FWIW - this solution is backwards compatible:
_env_variablesalready injectsPULP_SIGNING_KEY_FINGERPRINT, so this only overrides a value already passed; the kwarg is optional and defaults toNone(unlikeRpmPackageSigningService.sign(), which made it mandatory); the repo field is nullable; andvalidate()is unchanged since it signs with no fingerprint.Describe alternatives you've considered
validate()side effects, and re-opens the arbitrary-script-path security concern that stalled that issue.add-signing-serviceat runtime. Operationally fragile, couples callers to Pulp's pod internals, and produces a sprawl of per-key services.sign()honors a per-call fingerprint — which is why this pulpcore change is the prerequisite.