cvrf and cve endpoints don't list all package names that are listed on website for a given RHSA

[brixt0n]

Great tool. I was using it to attempt to get all updated packages from the RHSA / CVRF reference. I used the python module as follows:

import rhsda
a = rhsda.ApiClient()
a.get_cvrf("RHSA-2017:2489")

The json data returned here only included one updated package. However, visiting the errata page at https://access.redhat.com/errata/RHSA-2017:2489 and going to "Updated Packages", there are a whole raft of them.

[ryran]

Hi @brixt0n
I'm glad you're enjoying rhsecapi!

The json data returned here only included one updated package. However, visiting the errata page ... and going to "Updated Packages", there are a whole raft of them.

In RHEL, there are many cases where multiple binary rpms are built from a single source rpm, e.g.:

From openssl.src.rpm are built:

• openssl
• openssl-perl
• openssl-debuginfo
• (more)

Or from httpd.src.rpm are built:

• httpd
• mod_ssl
• (more)

Or of course from mercurial.src.rpm:

• mercurial
• emacs-mercurial
• mercurial-debuginfo
• (more)

In the case of RHSA-2017:2489 (xml), you have a bunch of rpms listed, but look closely and you'll see that (1) all of the packages are built from the same source rpm and (2) all of the listed packages depend on mercurial.rpm and (3) updating any one of the packages would require updating them all.

I didn't make the decision to omit child packages from cvrf/cve data (yes you'll run into the same "issue" if you use the API's cve endpoint), and I've never read about it, but I can see the logic behind it and I can tell you that it's normal. (Aside: You can check out Red Hat and CVRF compatibility and it's linked Sample Red Hat Security Advisory in CVRF 1.1 format to learn a bit more about CVRF, though this specific issue of the format is not addressed.)

Not sure what exactly you're looking for, but if you're wanting to check a system, you would be better off using existing tools (like the OpenSCAP vulnerability scanner that ships in RHEL) to operate on oval data. The oval data (e.g., xml) does include checks for all package names -- even though it could technically just list mercurial.rpm, since that's a dependency of all the others.

Let me know if you have any more questions.

[brixt0n]

Hi ryran

That's some really useful information, thank you.

My use case is around getting package names from a listing (e.g., rpm -qa) and then comparing these to names of packages which have been updated due to bugfixes. In that case, it sounds like implementing the API function calls myself and requesting the oval data may be the best way forward?

Thanks again for taking the time to reply.

[ryran]

My use case is around getting package names from a listing (e.g., rpm -qa) and then comparing these to names of packages which have been updated due to bugfixes.

I see.

In that case, it sounds like implementing the API function calls myself and requesting the oval data may be the best way forward?

Haha no not at all. Honestly it sounds like you're trying to invent the wheel when there are already multiple really good cars out there. :)

The first thing I would recommend is simply that you use yum. See my explanations in #71.

Alternatively, you could use oscap as described in the first example here in the RHEL7 security guide. Though if it were me, instead of downloading that 34 MiB uncompressed com.redhat.rhsa-all.xml file which includes details all the way back to RHEL3, I would go with a product-specific compressed file like com.redhat.rhsa-RHEL7.xml.bz2. You can see a sample html report I generated a while back from basically the same command. Note that there are tons more things you can do with oscap. See upstream docs for more.

Feel free to hit me back with more qs. Cheers.

[brixt0n]

Thanks for the info ryran.

I checked out com.redhat.rhsa-RHEL7.xml.bz2 but this also doesn't provide the rpm information I need.

Just to explain things a little more specifically, I would normally receive the output of rpm -qa, and compare these to the list of packages on the errata pages. Therefore I cannot run any commands (or the oscap tool) on a client's machine.

Appreciate any further info on this, and getting an accurate comparison.

[kymowang]

I have the same confusion. I get { "full_product_name": "mercurial-2.6.2-8.el7_4.src.rpm", "type": "Product Version", "name": "mercurial-0:2.6.2-8.el7_4" } from the api, but how can I get the exact rpm names on errata web page?
btw: what's the meaning of the 0 in "mercurial-0:2.6.2-8.el7_4"?

Attach a snapshot since I doubt if I describe the question clearly.