# Apollo, Errata, & You: a CIQ OSPO request for comment

**URL:** <https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102>\
**Category:** Release Engineering\
**Created:** [April 2, 2025, 5:56pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102 "2025-04-02T17:56:19Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![leigh](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/leigh/32/6077_2.png) [@leigh](https://forums.rockylinux.org/u/leigh)\
**Post date:** [April 2, 2025, 5:56pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/1 "2025-04-02T17:56:19Z")

</div>

There have been a number of documented issues with the Rocky Linux errata. Many of the issues with Rocky errata stem from the current state of the Apollo system which handles pulling in Red Hat errata information and then cloning it to Rocky. The Red Hat Hydra API is used as the initial source of truth for pulling in Red Hat advisory information as it contains information on security, bug, and enhancement advisories. However, this API is not always 100% accurate and can lead to inaccurate Rocky advisories.

The CIQ Open Source Program Office (OSPO) would like to work with the Rocky team to re-work Apollo to increase the accuracy of Rocky advisories starting with security advisories. This would entail moving from the Hydra API to using the Red Hat CSAF VEX files as the source of truth for Rocky Security advisories. The long term goal would be to get all errata to a more accurate and stable place but reducing the scope to only security advisories for the time being.

**The ask we have from the community is this** :  
What are your thoughts on temporarily shifting the focus of the Rocky Errata to be more focussed on security errata and trying to make these as accurate as possible? What are the downsides to doing this for the time being? Any concerns or thoughts? We want to ensure that any rebuild of this service provides what the community needs.

We’ll leave this thread for open comment until **4.16.25** , after which we’ll present a proposal. We know this situation with errata needs to be fixed, and we’re eager to dive in.

---

<div class="post-metadata">

**Author:** ![BenNickell](https://avatars.discourse-cdn.com/v4/letter/b/3e96dc/32.png) [@BenNickell](https://forums.rockylinux.org/u/BenNickell)\
**Post date:** [April 3, 2025, 3:02pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/2 "2025-04-03T15:02:30Z")

</div>

Yes please! This is very timely, as I was looking at determining patches for our upcoming patch day this morning! For instance, the newest security updates for Rocky8 on [errata.rockylinux.org](http://errata.rockylinux.org) show as February 26th, so either they are not being tagged or not being pushed.

Focusing on security updates errata is my highest concern with Rocky Linux, let us know if we can help in any way.

---

<div class="post-metadata">

**Author:** ![Vittory003](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/vittory003/32/4694_2.png) [@Vittory003](https://forums.rockylinux.org/u/Vittory003)\
**Post date:** [April 4, 2025, 7:31am UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/3 "2025-04-04T07:31:28Z")

</div>

Hi,  
Yes, it is very important for us to be able to manage security errata.  
It allows us to have a stable environment in production and use Foreman for patching.

If I can help, I will do so gladly.

---

<div class="post-metadata">

**Author:** ![anthyve](https://avatars.discourse-cdn.com/v4/letter/a/b2d939/32.png) [@anthyve](https://forums.rockylinux.org/u/anthyve)\
**Post date:** [April 4, 2025, 11:18am UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/4 "2025-04-04T11:18:38Z")

</div>

We rely on errata to determine security patches, not other kinds of changes. So temporary shift in focus to stabilize this subset makes total sense to me.

---

<div class="post-metadata">

**Author:** ![Thomas](https://avatars.discourse-cdn.com/v4/letter/t/e36b37/32.png) [@Thomas](https://forums.rockylinux.org/u/Thomas)\
**Post date:** [April 4, 2025, 4:07pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/5 "2025-04-04T16:07:35Z")

</div>

Hello,  
Same here, it would be really nice to have security erratas as soon as possible (to integrate them in foreman content views in my case).  
Concerning bug and enhancement advisories, we can wait to publish new content views with all RPMs that will be tested and slowly published to production env.  
I will be glad to help or test if needed too.  
Thanks for the efforts on this subject.

---

<div class="post-metadata">

**Author:** ![WerVa](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/werva/32/5322_2.png) [@WerVa](https://forums.rockylinux.org/u/WerVa)\
**Post date:** [April 4, 2025, 9:48pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/6 "2025-04-04T21:48:25Z")

</div>

yes it’s a great solution because I manage errata in forman planning mass machine updates!

---

<div class="post-metadata">

**Author:** ![riverhawk2002](https://avatars.discourse-cdn.com/v4/letter/r/c67d28/32.png) [@riverhawk2002](https://forums.rockylinux.org/u/riverhawk2002)\
**Post date:** [April 4, 2025, 10:11pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/7 "2025-04-04T22:11:25Z")

</div>

I feel that resolving processing issues with security errata and ensuring its stability/reliability as a first and foremost priority is proper and a correct action plan. It becomes very difficult to accurately paint a complete security picture to one’s stakeholders without the pertinent and verifiable data. Additionally, compliance activities such as audits and reports are a more manual process. The major third-party security tooling providers which also depends on this data to be readily available can’t provide the automation to run their tools against the errata, leading to missing information.

The pitfall to be cognizant of would be that once the security errata has been restored to a stable and functional process, is to not delay and apply the corrected methods to bug fixes and enhancement errata as resources permit. While not as pressing as security matters, these items are still crucial to the overall structure and health of the Rocky Linux OS. It’s very tidy to use when you caught in a unique situation to patch a bug or release an enhancement feature and want to see if this resolves any issues at hand.

I’m very pleased to see that there is a focused effort in resolving this issue with a long term plan and roadmap!

---

<div class="post-metadata">

**Author:** ![wagner-robert](https://avatars.discourse-cdn.com/v4/letter/w/b9bd4f/32.png) [@wagner-robert](https://forums.rockylinux.org/u/wagner-robert)\
**Post date:** [April 7, 2025, 1:52pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/8 "2025-04-07T13:52:32Z")

</div>

I will add my emphasis to the need for Enterprise Errata and OVAL files/outputs. The current OVAL files derived from the errata: [Index of /pub/oval/](https://dl.rockylinux.org/pub/oval/) do not work in OpenSCAP. Lacking the ability to verify the Rocky Linux system is locked down and is up to data on patches, means the software is **NOT** enterprise ready in the eyes of our organization. The lock-down check from the STIG if fine, but the OVAL generates errors and cannot be used. I greatly appreciate efforts to get this fully functional again, so do not take this as slander to those donating their time to develop. I am happy to test and provide any insight I can, but I am not a developer. Some Issues are identified here: [GitHub - rocky-linux/oval: OVAL file generator](https://github.com/rocky-linux/oval). Thanks again for your support!

---

<div class="post-metadata">

**Author:** ![leigh](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/leigh/32/6077_2.png) [@leigh](https://forums.rockylinux.org/u/leigh)\
**Post date:** [April 16, 2025, 2:25pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/9 "2025-04-16T14:25:22Z")

</div>

The public comment period is now closed. As there has been no disagreement to the proposal of focusing on improving the accuracy of security updates, this is the approach we will take.

1. We’re going to work on the existing tooling (Apollo) to improve security update accuracy. We need to get the tooling to a state where updates are reliably identified and matched to their associated builds and the information for them is appropriately enriched.

2. Simultaneously, we’re going to work on implementing additional automation to the current build process so that when updates are made available, manual effort is not required to ingest the updates, patch them, and then push the new build. This will ensure updates are made available as soon as possible.

Every Tuesday at 1300 EST we will have a standup with the engineers leading these efforts, with the first set for 4.22.25. These will be open to the public to attend, and posted on the Rocky calendar. Anyone can drop in to get status updates, progress, etc.

We’ll also be updating this thread as we make progress so the community is kept up-to-date along the way.

---

<div class="post-metadata">

**Author:** ![leigh](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/leigh/32/6077_2.png) [@leigh](https://forums.rockylinux.org/u/leigh)\
**Post date:** [April 29, 2025, 5:24pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/10 "2025-04-29T17:24:47Z")

</div>

Progress on this continues to go well. After a period of discovery, as planned we’ve outlined where things are at with Apollo, current issues, and a path forward broken into phases. That document is public, and can be viewed here:

> **[Apollo](https://docs.google.com/document/d/1qoYYLcJ4m2dgDLmnUTIQ3lF1KSc5QeKAssfhsVRz3v4/edit?tab=t.0#heading=h.kf027viwduc)**
>
> Background Apollo is used to mirror Red Hat Linux errata data to produce equivalent advisories for Rocky Linux. It’s a key piece of infrastructure for maintaining downstream security parity—but it currently faces several significant technical and...

By moving to Red Hat CSAF instead of Hydra for updates, we believe we’ll be able to pull in not only security, but bug fixes and other advisories as well.

We’ll look to have an update out by end of next week on the status of phase 1.

---

<div class="post-metadata">

**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\
**Post date:** [April 30, 2025, 4:05am UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/11 "2025-04-30T04:05:51Z")

</div>

> Do we clone advisories that contain fixes that were released into Extended Update Support (EUS) repositories?

No, we do not deal with nor do we support EUS or any other prior release.

> **[Rocky Linux Release and Version Guide - Rocky Linux Wiki](https://wiki.rockylinux.org/rocky/version/#__tabbed_1_1)**
>
> The wiki for the Rocky Linux project

---

<div class="post-metadata">

**Author:** ![leigh](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/leigh/32/6077_2.png) [@leigh](https://forums.rockylinux.org/u/leigh)\
**Post date:** [May 15, 2025, 3:30pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/12 "2025-05-15T15:30:57Z")

</div>

Here’s a PR covering the first phase in the above linked tracker, the CSAF ingestion proof of concept:

> <https://github.com/resf/distro-tools/pull/44>
>
> \# CSAF Advisory Ingestion System
> 
> \## Overview
> This PR implements a new CSAF-b…ased advisory ingestion system replacing the HYDRA API for Red Hat errata information, along with test coverage. The overall project plan can be found \[here\](https://docs.google.com/document/d/1qoYYLcJ4m2dgDLmnUTIQ3lF1KSc5QeKAssfhsVRz3v4/edit?usp=sharing).
> 
> \## Implementation Details
> 
> \### Core Features
> \* New \`rhcsaf\` library for CSAF advisory processing
> \* New \`rpm\_helpers\` library for RPM NEVRA parsing
> \* CSAF file parsing and data extraction
> \* Temporal workflow for advisory processing
> \* Module NEVRA product version detection
> \* Multi-format timestamp handling
> 
> \### Test Coverage
> \* Unit tests for RPM helpers
> - NEVRA parsing (modular/non-modular)
> - Distribution version extraction
> - Release string handling
> \* Tests for RHCSAF processing
> - Advisory scraping
> - Data extraction
> - Schema validation
> \* Tests for CSAF processing
> - Document parsing
> - Security/bugfix/enhancement advisories
> - Database operations validation
> 
> \### CI Integration
> \* Added Bazel test targets
> \* Updated GitHub workflow
> 
> \## Testing
> Run the test suite:
> \`\`\`bash
> $ bazel test --cache\_test\_results=no //apollo/tests:test\_rpm\_helpers --test\_output=all
> bazel test --cache\_test\_results=no //apollo/tests:test\_rhcsaf --test\_output=all
> bazel test --cache\_test\_results=no //apollo/tests:test\_csaf\_processing --test\_output=all
> INFO: Analyzed target //apollo/tests:test\_rpm\_helpers (0 packages loaded, 0 targets configured).
> INFO: Found 1 test target...
> INFO: From Testing //apollo/tests:test\_rpm\_helpers:
> ==================== Test output for //apollo/tests:test\_rpm\_helpers:
> ...
> \----------------------------------------------------------------------
> Ran 3 tests in 0.000s
> 
> OK
> ================================================================================
> Target //apollo/tests:test\_rpm\_helpers up-to-date:
> bazel-bin/apollo/tests/test\_rpm\_helpers
> INFO: Elapsed time: 0.367s, Critical Path: 0.29s
> INFO: 2 processes: 2 linux-sandbox.
> INFO: Build completed successfully, 2 total actions
> //apollo/tests:test\_rpm\_helpers PASSED in 0.2s
> 
> Executed 1 out of 1 test: 1 test passes.
> INFO: Build completed successfully, 2 total actions
> INFO: Analyzed target //apollo/tests:test\_rhcsaf (0 packages loaded, 0 targets configured).
> INFO: Found 1 test target...
> INFO: From Testing //apollo/tests:test\_rhcsaf:
> ==================== Test output for //apollo/tests:test\_rhcsaf:
> ================================================================================
> Target //apollo/tests:test\_rhcsaf up-to-date:
> bazel-bin/apollo/tests/test\_rhcsaf
> INFO: Elapsed time: 0.494s, Critical Path: 0.42s
> INFO: 2 processes: 2 linux-sandbox.
> INFO: Build completed successfully, 2 total actions
> //apollo/tests:test\_rhcsaf PASSED in 0.3s
> 
> Executed 1 out of 1 test: 1 test passes.
> INFO: Build completed successfully, 2 total actions
> INFO: Analyzed target //apollo/tests:test\_csaf\_processing (0 packages loaded, 0 targets configured).
> INFO: Found 1 test target...
> INFO: From Testing //apollo/tests:test\_csaf\_processing:
> ==================== Test output for //apollo/tests:test\_csaf\_processing:
> ================================================================================
> Target //apollo/tests:test\_csaf\_processing up-to-date:
> bazel-bin/apollo/tests/test\_csaf\_processing
> INFO: Elapsed time: 0.871s, Critical Path: 0.80s
> INFO: 2 processes: 2 linux-sandbox.
> INFO: Build completed successfully, 2 total actions
> //apollo/tests:test\_csaf\_processing PASSED in 0.6s
> 
> Executed 1 out of 1 test: 1 test passes.
> INFO: Build completed successfully, 2 total actions
> \`\`\`
> 
> \## Notes
> CSAF ingestion introduces some NEVRA handling changes:
> \* Epochs now present in Red Hat NEVRA entries
> \* No \`.rpm\` suffixes in NEVRA entries
> 
> These will be addressed in a follow-up PR.

Unless there’s an objection, we’d like to merge this by next Tuesday, the 20th. It’s gone through extensive review by multiple CIQ engineers, but we’d like community and Rocky engineer reviews as well.

---

<div class="post-metadata">

**Author:** ![sthornton](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/sthornton/32/5320_2.png) [@sthornton](https://forums.rockylinux.org/u/sthornton)\
**Post date:** [May 21, 2025, 4:50pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/13 "2025-05-21T16:50:01Z")

</div>

The Phase 2 implementation of the CSAFv2-based ingestion workflow is now complete, and the pull request is available for review:

🔗 [https://github.com/resf/distro-tools/pull/45](https://github.com/resf/distro-tools/pull/45)

### **What’s Included:**

- Replaces HYDRA-based security advisory ingestion with a CSAFv2-driven workflow.

- Streams and parses CSAF files directly from Red Hat, filtered to the past 30 days.

- Adds new logic for extracting affected products (including `noarch` expansion and arch mapping).

- Improves logging and error handling throughout ingestion and advisory processing.

- Adds shared NEVRA parsing utilities to reduce duplication.

- Includes expanded test coverage for CSAF parsing, edge cases, and advisory creation.

- Lays groundwork for future parallelization and backfill support.

This work aligns with **Phase 2** of the ongoing advisory ingestion overhaul and sets the stage for production rollout in a future phase.  
🔗[Apollo Refactor Doc](https://docs.google.com/document/d/1qoYYLcJ4m2dgDLmnUTIQ3lF1KSc5QeKAssfhsVRz3v4/edit?usp=sharing)

Thanks in advance to anyone who has time to review!

---

<div class="post-metadata">

**Author:** ![leigh](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/leigh/32/6077_2.png) [@leigh](https://forums.rockylinux.org/u/leigh)\
**Post date:** [June 26, 2025, 2:31pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/14 "2025-06-26T14:31:36Z")

</div>

Hi folks, it’s been a while since our last update, but we’re happy to announce that phase 3 is complete. All that remains is for the revamped Apollo to be integrated into production. Once that’s completed, we’ll provide an update.

---

<div class="post-metadata">

**Author:** ![sthornton](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/sthornton/32/5320_2.png) [@sthornton](https://forums.rockylinux.org/u/sthornton)\
**Post date:** [June 26, 2025, 5:54pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/15 "2025-06-26T17:54:10Z")

</div>

For those interested, here is the Pull Request for the phase 3 work:

> <https://github.com/resf/distro-tools/pull/48>
>
> \# Changes
> Introduces new helper functions for both \`RHMatcher\` and \`PollRHCSAFA…dvisoriesWorkflow\` which handle adding and removing associated advisory information from both Red Hat advisories and their cloned Rocky counterparts.
> 
> 
> 
> \# Testing
> 
> \`\`\`
> $ personal\_work\_dir/phase3\_tester.sh
> 
> 
> ========================================
> Testing Updates for Updates to rh\_matcher
> ========================================
> 
> \--- Truncate all tables in the database... ---
> NOTICE: truncate cascades to table "advisories"
> NOTICE: truncate cascades to table "red\_hat\_advisory\_affected\_products"
> NOTICE: truncate cascades to table "red\_hat\_advisory\_bugzilla\_bugs"
> NOTICE: truncate cascades to table "red\_hat\_advisory\_cves"
> NOTICE: truncate cascades to table "red\_hat\_advisory\_packages"
> NOTICE: truncate cascades to table "supported\_products\_rh\_blocks"
> NOTICE: truncate cascades to table "supported\_products\_rpm\_rh\_overrides"
> NOTICE: truncate cascades to table "advisory\_affected\_products"
> NOTICE: truncate cascades to table "advisory\_cves"
> NOTICE: truncate cascades to table "advisory\_fixes"
> NOTICE: truncate cascades to table "advisory\_packages"
> TRUNCATE TABLE
> 
> \--- Reset the red\_hat\_index\_state table... ---
> UPDATE 1
> 
> \--- Restart each worker/server ---
> Restarting tmux session 'apollo-server'...
> Restarting tmux session 'temporal'...
> Restarting tmux session 'rhworker'...
> Restarting tmux session 'rpmworker'...
> 
> \--- Kicking off Temporal workflow to populate the Red Hat advisories... ---
> Starting workflow: PollRHCSAFAdvisoriesWorkflow on task queue: v2-rhworker
> Running execution:
> WorkflowId 5209f50d-ff54-485e-b102-4ce0727fbd11
> RunId 01977ec7-3dd6-7e1c-a989-c61e0a8b1025
> Type PollRHCSAFAdvisoriesWorkflow
> Namespace default
> TaskQueue v2-rhworker
> 📡 Monitoring workflow with ID: 5209f50d-ff54-485e-b102-4ce0727fbd11...
> Workflow status:
> ⏳ Workflow is still running...
> Workflow status:
> ⏳ Workflow is still running...
> Workflow status: COMPLETED
> ✅ PollRHCSAFAdvisoriesWorkflow completed successfully.
> Starting workflow: RhMatcherWorkflow on task queue: v2-rpmworker
> Running execution:
> WorkflowId e7a7cca8-07a0-4cbb-8bcb-c6a541b12f24
> RunId 01977ec7-abc2-7389-8605-e44d4509ab2f
> Type RhMatcherWorkflow
> Namespace default
> TaskQueue v2-rpmworker
> 📡 Monitoring workflow with ID: e7a7cca8-07a0-4cbb-8bcb-c6a541b12f24...
> Workflow status: COMPLETED
> ✅ RhMatcherWorkflow completed successfully.
> 
> \--- Deleting some data for RHSA-2025:8756... ---
> Delete two packages
> DELETE 2
> Delete two CVEs
> DELETE 2
> Modify one CVE base\_score
> UPDATE 1
> Delete two Bugzilla bugs
> DELETE 2
> 
> \--- Reset the red\_hat\_index\_state table... ---
> UPDATE 1
> Starting workflow: RhMatcherWorkflow on task queue: v2-rpmworker
> Running execution:
> WorkflowId 05a08586-ddb6-47fc-9937-2983520807a7
> RunId 01977eca-1766-7df0-b664-26a1342d73dc
> Type RhMatcherWorkflow
> Namespace default
> TaskQueue v2-rpmworker
> 📡 Monitoring workflow with ID: 05a08586-ddb6-47fc-9937-2983520807a7...
> Workflow status: COMPLETED
> ✅ RhMatcherWorkflow completed successfully.
> 
> \--- Reviewing RHMatcher log for add/remove actions on RHSA-2025:8756 after manual deletions ---
> (expecting to see removal entries for deleted items and updated CVE)
> \[apollorpmworker:INFO:2025-06-17 10:50:08,960\] Removing 1 packages from advisory RLSA-2025:8756
> \[apollorpmworker:INFO:2025-06-17 10:50:08,961\] Updating CVE CVE-2025-3909 for advisory RLSA-2025:8756
> \[apollorpmworker:INFO:2025-06-17 10:50:08,961\] Removing 2 CVEs from advisory RLSA-2025:8756
> \[apollorpmworker:INFO:2025-06-17 10:50:08,963\] Removing 2 fixes from advisory RLSA-2025:8756
> 
> 
> ========================================
> Testing Updates to poll\_rh\_activites workflow
> ========================================
> 
> \--- Inserting dummy data for RHSA-2025:8756 ---
> Inserting dummy RPMS for RHSA-2025:8756...
> INSERT 0 1
> Inserting dummy CVEs for RHSA-2025:8756...
> INSERT 0 1
> Inserting dummy Bugzillas for RHSA-2025:8756...
> INSERT 0 1
> Inserting dummy affected products for RHSA-2025:8756...
> INSERT 0 1
> Reset the red\_hat\_index\_state table so that the workflow will reprocess the data...
> UPDATE 1
> Starting workflow: PollRHCSAFAdvisoriesWorkflow on task queue: v2-rhworker
> Running execution:
> WorkflowId 639ec930-4a6d-4ccc-b628-80b2db8ee42f
> RunId 01977ecc-8318-720e-bb30-408eae14f8ef
> Type PollRHCSAFAdvisoriesWorkflow
> Namespace default
> TaskQueue v2-rhworker
> 📡 Monitoring workflow with ID: 639ec930-4a6d-4ccc-b628-80b2db8ee42f...
> Workflow status: COMPLETED
> ✅ PollRHCSAFAdvisoriesWorkflow completed successfully.
> 
> \--- Checking log for removal messages ---
> \[apollorhworker:INFO:2025-06-17 10:50:27,003\] Removing packages for advisory RHSA-2025:8756: {'test-rpm-0:1.1-2.2.el8\_10.noarch'}
> \[apollorhworker:INFO:2025-06-17 10:50:27,011\] Removing CVEs for advisory RHSA-2025:8756: {'CVE-9999-0000'}
> \[apollorhworker:INFO:2025-06-17 10:50:27,012\] Removing CVEs for advisory RHSA-2025:8756: {'CVE-9999-0000'}
> \[apollorhworker:INFO:2025-06-17 10:50:27,015\] Removing Bugzilla bugs for advisory RHSA-2025:8756: {'1234567'}
> \[apollorhworker:INFO:2025-06-17 10:50:27,016\] Removing affected products for advisory RHSA-2025:8756: {('RHEL', 'DUMMY NAME', Decimal('99'), None, 'noarch')}
> \[apollorhworker:INFO:2025-06-17 10:50:27,009\] Updating CVE CVE-2025-3909 for advisory RHSA-2025:8756
> 
> Checking database for dummy data...
> id | red\_hat\_advisory\_id | nevra
> \----+---------------------+-------
> (0 rows)
> 
> id | red\_hat\_advisory\_id | cve | cvss3\_scoring\_vector | cvss3\_base\_score | cwe
> \----+---------------------+-----+----------------------+------------------+-----
> (0 rows)
> 
> id | red\_hat\_advisory\_id | bugzilla\_bug\_id | description
> \----+---------------------+-----------------+-------------
> (0 rows)
> 
> id | red\_hat\_advisory\_id | variant | name | major\_version | minor\_version | arch
> \----+---------------------+---------+------+---------------+---------------+------
> (0 rows)
> (0 rows)
> \`\`\`

---

<div class="post-metadata">

**Author:** ![sthornton](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/sthornton/32/5320_2.png) [@sthornton](https://forums.rockylinux.org/u/sthornton)\
**Post date:** [June 26, 2025, 5:55pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/16 "2025-06-26T17:55:38Z")

</div>

There is also a PR open to start using the new workflow in the Apollo cron: [replace PollRHAdvisoriesWorkflow with PollRHCSAFAdvisoriesWorkflow by rockythorn · Pull Request #49 · resf/distro-tools · GitHub](https://github.com/resf/distro-tools/pull/49)

Also a bugfix for an issue seen when trying to use the original workflow after some of my changes: [bug fix: timezone support upsert\_last\_indexed\_at function by rockythorn · Pull Request #50 · resf/distro-tools · GitHub](https://github.com/resf/distro-tools/pull/50)

---

<div class="post-metadata">

**Author:** ![HowardHolcombe](https://avatars.discourse-cdn.com/v4/letter/h/8dc957/32.png) [@HowardHolcombe](https://forums.rockylinux.org/u/HowardHolcombe)\
**Post date:** [July 8, 2025, 8:26pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/17 "2025-07-08T20:26:49Z")

</div>

any new status on workflow ? Anything I can do to assist?

---

<div class="post-metadata">

**Author:** ![leigh](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/leigh/32/6077_2.png) [@leigh](https://forums.rockylinux.org/u/leigh)\
**Post date:** [July 8, 2025, 8:59pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/18 "2025-07-08T20:59:15Z")

</div>

The Apollo fixes are complete, and now the work that needs to be done is how to allow for automation of the appropriate workflows. @sthornton can you outline this a little more, please?

---

<div class="post-metadata">

**Author:** ![sthornton](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/sthornton/32/5320_2.png) [@sthornton](https://forums.rockylinux.org/u/sthornton)\
**Post date:** [July 11, 2025, 7:55pm UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/19 "2025-07-11T19:55:32Z")

</div>

My current understanding that there were / are two main issues that have prevented the full automation of errata generation:

1. Concerns about the data quality of artifacts produced by Apollo and therefore a desire to do some sort of manual validation when the Rocky advisory generation workflow (RhMatcherWorkflow) is run.
2. Lack of automation to produce and publish the corresponding `updateinfo` `.xml` files that need to be in the repos following the generation or update of Rocky security advisories.

The work I’ve done on Apollo should alleviate number 1, however number 2 will still be an issue as it wasn’t included in the original scope of the Apollo refactor project. I can continue to work with the RESF to see if we can develop a solution for automating the generation and publishing of updateinfo.

---

<div class="post-metadata">

**Author:** ![riverhawk2002](https://avatars.discourse-cdn.com/v4/letter/r/c67d28/32.png) [@riverhawk2002](https://forums.rockylinux.org/u/riverhawk2002)\
**Post date:** [August 12, 2025, 10:45am UTC](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102/20 "2025-08-12T10:45:44Z")

</div>

Good morning, just wondering if there is a status update to continue with the excellent progress which has been made thus far.. Even though I’m a just a BA, I will be happy to share some of the number differences when the automated errata updates are completed.. I get it if it’s a long pole. just trying to determine a timeline for my security engineering stakeholders.

[Next page](https://forums.rockylinux.org/t/apollo-errata-you-a-ciq-ospo-request-for-comment/18102.md?page=2)
