[GSOC23] - D - Define RPC endpoints for listing the affected packages regarding a CVE #7570
Conversation
- This is a temporary implementation based on JAXB API which consumes a lot of memory. I plan to rewrite it with StAX for better performance.
- A utility class to access OVAL resources (tests, objects and states) by id and quickly
- Used to parse CPEs found in OVAL files.
- Used to create CPE objects for testing and for when CPE is not available in OVAL, and we need to create or infer our own.
- OVAL files usually encode vulnerable operating systems information as a CPE (Common Platform Enumeration). Therefore, in order to accurately audit client systems we need to store their CPE.
- Kind of migration strategy for minions that are already registered. Instead of re-registering the minion, users could update their package list to get assigned a CPE.
- Added AFFECTED_PARTIAL_PATCH_APPLICABLE and AFFECTED_PARTIAL_PATCH_APPLICABLE - Also renamed 'AFFECTED_PATCH_APPLICABLE' to 'AFFECTED_FULL_PATCH_APPLICABLE'
- This way when we can't audit a system with OVAL we can fall back to the old code.
- Because we don't need all the information contained in PackageListItem for CVE auditing.
- The idea here is decouple CVEAuditManager from the rest of the code by replacing all calls to CVEAuditManager to CVEAuditManagerOVAL, and make the CVEAuditManagerOVAL#doAuditSystem method fallback to CVEAuditManager#doAuditSystem when the system cannot be audited with OVAL (OVAL not synced or not supported by the system's OS). This way, in the future, when all distributions become supported for performing OVAL-based CVE auditing, we can just delete CVEAuditManager and its test class. - CVEAuditManager contains also methods for managing CVE channels. For now, we can create the same methods in CVEAuditManagerOVAL and redirect them to their equivalent in CVEAuditManager. But in the future, when we don't need CVEAuditManager anymore, we can move them entirely to CVEAuditManagerOVAL or put them in their own class. - The upside is that we can keep the tests for CVEAuditManager, which tests the channels-based algorithm, and we make the transition later when we don't need the channels algorithm anymore, easier. The downside is a lot of potential duplication in CVEAuditManagerOVAL tests given that need to maintain both channels and OVAL-based implementations.
- Now, CVEAuditManager is only used by CVEAuditManagerOVAL and CVEAuditManagerTest
- Also, updated the icons and colors of some patch statuses labels
Suggested tests to cover this Pull Request
|
|
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
@rjmateus Can you please remove the stale label again to prevent closing it? |
Done |
|
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
This PR was closed because it has been stalled for 10 days with no activity. |
|
Reopening |
|
👋 Hello! Thanks for contributing to our project. If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code. Reference tests: KNOWN ISSUES Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience. For more tips on troubleshooting, see the troubleshooting guide. Happy hacking! |
|
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
do not close |
What does this PR change?
Scanning for a CVE from the web UI will give you whether your system is vulnerable or not along with patches to apply. But you don't know what packages need to be patched. This information is not important if Uyuni could apply the patch automatically, but if the patch is unavailable, you'll need to know what packages to patch manually. The goal of this pull request is to provide users with the list of packages to be patched regarding a particular CVE. All from Spacecmd.
GUI diff
No difference.
Documentation
No documentation needed: add explanation. This can't be used if there is a GUI diff
No documentation needed: only internal and user invisible changes
Documentation issue was created: Link for SUSE Manager contributors, Link for community contributors.
API documentation added: please review the Wiki page Writing Documentation for the API if you have any changes to API documentation.
(OPTIONAL) Documentation PR
DONE
Test coverage
No tests: add explanation
No tests: already covered
Unit tests were added
Cucumber tests were added
DONE
Links
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run: