v0.6.0

This release builds the registry on FOCA 0.18 and adds what deployments with
several identity providers and active admins need: admins act as admins
only in admin mode, several token issuers can be trusted (with user
identifiers namespaced by issuer), admins can change the identifier of a
service, and the service info publishes the deployment's rules for
registrations. Some of these changes are breaking (see below): every
deployment must set its public URL (server.public_url), the 0.6.0 chart
needs 0.6.0 images, and clients and UIs must ask for admin mode. Deployments
of 0.5.0 keep their data: read the upgrade
steps
first. See the
documentation for
details.

Breaking changes

• Config: custom.endpoints.service is removed; every deployment must set
  FOCA's server.public_url to the absolute URL of the app as clients see
  it (e.g., https://registry.example.org/), or the app (each Gunicorn
  worker) refuses to start. custom.access_control.require_admin moves to
  security.access_control.require_admin; the old keys are rejected. The
  image loads FOCA's Gunicorn settings (foca.gunicorn_config; same
  settings), and startup checks of groups, admins and the service info are
  FOCA's, with FOCA's messages (#226, #261)
• Helm chart: the chart sets config.server.public_url (from hostName,
  or the new value publicUrl) and rejects the removed keys, so the 0.6.0
  chart needs images built with FOCA 0.18 (0.6.0 or later); older images
  refuse to start (#226, #261)
• Access control: admins act as admins only in admin mode, i.e., in
  requests with the header X-Request-Roles: admin; otherwise they have the
  permissions of other users. GET /me reports admin only in admin mode
  and has the new field admin_available. Configured rules that grant the
  role admin are refused on startup; grants of admin stored via the
  permissions API still apply without admin mode (FOCA warns of them on
  startup): revoke them, and make users admins via admin groups instead.
  Clients and scripts that need admin rights must send the header: deploy a
  UI that sends it before upgrading (e.g., cloud-registry-ui with its admin
  mode switch), or set security.access_control.opt_in_roles: [] until
  then (#240, #263)
• Access control: the policy rule owners-change-permissions covers
  /services/:id/permissions/* (before: .../permissions/:user), so that
  user identifiers may contain slashes; it also covers the roles of groups.
  Overlays that removed only owners-change-group-permissions to stop
  owners from granting roles to groups must also change
  owners-change-permissions; the app warns on startup of rules that still
  let owners do so (#257, #264; #268, #275)
• API: changes of a service (PUT, DELETE, granting and revoking roles)
  may return 409 Conflict with the code service-busy while the service
  is renamed (try again); see the new rename endpoint below (#243, #262)

Features

• Several token issuers: deployments can trust several identity providers;
  with several, user identifiers are namespaced by issuer
  (<namespace>|<sub>, also in roles and GET /me), and may contain
  slashes. The chart accepts issuers with their own audience and group
  claim. Deployments that add an issuer can keep the subjects of the issuer
  trusted so far bare (namespace: "") or migrate them with
  python -m cloud_registry.namespace_subjects (#257, #264)
• Admin mode (X-Request-Roles: admin), with admin_available in
  GET /me, so that UIs can offer a switch (#240, #263)
• Renames: admins can change the identifier of a service
  (POST /services/{serviceId}/rename); the service keeps its roles, user
  names, verification and createdAt. New identifiers that are taken return
  409 Conflict with the code service-id-taken. Renames lock both
  identifiers (new collection service_locks, created on startup), and
  interrupted renames are finished when the app starts or handles requests
  of the registry's operations (#243, #262)
• Service info: registration_rules in GET /service-info publishes the
  deployment's rules for registrations (allowed environments and URL
  schemes, the mode of service types and the limit of unused types), so
  that clients don't need to configure them (#256, #260)

Security

• API: user identifiers and groups with the segments . or .. (e.g.,
  .., a/../b) are rejected in permission paths (400 Bad Request), as
  clients resolve them in URLs (#252, #259)
• Startup: the app warns if the rule of owners' roles of groups is changed
  or removed, but other configured rules still let owners grant and revoke
  roles of groups (#268, #275)
• Image: the msgpack copy that pip vendors in the base image
  (CVE-2026-114613) is accepted until 2027-01-31, as the app doesn't use it
  and pip's latest release still vendors it (#272, #273)

Fixes

• The Swagger UI (the probe path of the chart and the image's health
  check), the spec and /service-info no longer depend on MongoDB: only
  requests of the registry's operations resume interrupted renames, and
  database errors while checking for them are logged instead of failing
  the request (#267, #269)

Documentation

• Upgrade steps from 0.5.0: the public URL, admins, Gunicorn, admin mode
  (also during rolling updates and with web UIs), the owners' rules of
  groups, and adding a token issuer (#226, #261; #240, #263; #257, #264;
  #268, #275)
• Access control: restricting owners to users' roles, also with namespaced
  issuers; GET /me user_id is namespaced by issuer; FOCA's permissions
  API doesn't wait for renames (#268, #275)
• Community files (code of conduct, contributing, security policy) come
  from the organization's defaults; the developer guide stays in the docs
  (#265, #266)

Commits

• feat: publish the registration rules by @uniqueg in #260
• fix: reject dot segments as principals by @uniqueg in #259
• feat: let admins change a service's ID by @uniqueg in #262
• refactor!: use FOCA 0.18 features by @uniqueg in #261
• feat: add admin mode by @uniqueg in #263
• feat: support several token issuers by @uniqueg in #264
• docs: use the org-wide community files by @uniqueg in #266
• ci: accept msgpack CVE vendored by pip by @uniqueg in #273
• fix: keep probes independent of the database by @uniqueg in #269
• fix: close the 0.6.0 review gaps by @uniqueg in #275
• chore: prepare release 0.6.0 by @uniqueg in #277

Full Changelog: v0.5.0...v0.6.0