In fact the best place to report these issues is the Infrastructure repository https://github.com/osrf/infrastructure which has issue templates to guide reporters in collecting information that help the Infrastructure team triage and respond to such reports.
In short, no. The repository signing keys are in many ways the most important individual assets that OSRF manages, since they provide the trust for OSRF distributed binaries. Additionally, just about any change to the keys themselves is likely to require manual changes for every configured system in the community that utilizes the ROS or OSRF repositories. These two facts have led to a bit of paralysis on the Infrastructure team’s side as we have striven to make exactly one “perfect” migration. Furthermore, the understanding of hardware-backed keys and managed subkeys implied by that outline also turned out to be quite incomplete when the infrastructure team attempted to actually put it into practice.
The transition did occupy infrastructure staff who may have otherwise continued the key handling work with fewer or milder interruptions but the transition also re-emphasized the need to improve our rotation and handling of repository keys now that infrastructure staff need not be employed or contracted directly by OSRF.
Perhaps ironically, perhaps fatefully, @jrivero and I actually had the first conversations about resuming the work on updating our GPG key rotation practices at the end of last week with an eye toward the Ubuntu 24.04 release next April.
During the prior GPG key expiration incident, we intentionally set the expiration date to survive the full LTS length of Ubuntu 20.04 but we did not look at the ROS Snapshots repository which runs on separate infrastructure. The snapshots repository has always been operated on a best-effort basis rather than considered one of the “core” infrastructure services provided by OSRF.