I’d like to revisit the topic of automating the RHMatcherWorkflow for publishing security advisories, with a new approach that might address some of the core concerns raised previously.
Rather than attempting to automate advisories from internal or dev repositories (which risks generating advisories for builds that aren’t actually released), what if we instead point RHMatcher to the public repositories? This would mean that security advisories would only be generated after a compose is made public, introducing a delay of one compose cycle per repository. However, this would ensure that advisories always match what’s actually available to users, while also enabling more regular and predictable updates.
I see this as an incremental improvement over the current process, where significant gaps can occur between advisories. With this method, advisories might lag by a compose, but they would be consistently updated in line with public releases—providing much more timely info for users and tooling relying on Apollo.
I’d love to hear thoughts on:
-
The feasibility of using only public repos for automated advisory generation
-
Any technical or process blockers to this approach
-
Potential risks or downsides I might not be considering
-
How we might pilot or incrementally roll this out
Thanks as always for your hard work and for considering this idea. Looking forward to the discussion!