-
Notifications
You must be signed in to change notification settings - Fork 468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: "language" parser for rpm SPEC files #2916
Comments
CVEBnTool_Team3 working on this |
The rpm are built using SPEC file, but the final result is in the Lead Section and Header Section more details here: here is sample dump from fedora emacs rpm:
Unfortunately as we can see the Vendor is set to Fedora Project I've checked the OpenSuse rpm for comparision:
And the Vendor is set to the distro. So we could get from the rpm file for the name and version, but not the vendor, I could try to extract it from the Summary, but i think it will be error-prone |
Got the nice output
all checkers disabled, only languages enabled, and emacs not even yet in checkers :) need to cleanup code and peer review, and will post pr later |
* fixes intel#2916 Signed-off-by: Bartlomiej Cieszkowski <bartlomiej.cieszkowski@intel.com> Signed-off-by: Przemyslaw Romaniak <przemyslaw.romaniak@intel.com>
* fixes intel#2916 Signed-off-by: Bartlomiej Cieszkowski <bartlomiej.cieszkowski@intel.com> Signed-off-by: Przemyslaw Romaniak <przemyslaw.romaniak@intel.com>
Since this issue is still open, I checked the PR related to this issue. This pull request added a parser for RPM files based on the RPM file format. The test for file "test/condensed-downloads/dovecot-2.3.14-1.fc34.i686.rpm" in line 137 of "test/test_helper_script.py" file fails. And this test fails because |
@tahifahimi That sounds reasonable. This one just didn't get finished during the hackathon and everyone moved on to other projects. If you want to propose a fix for the test, we can integrate that and get this merged. |
The purpose of this test was to have a better (more beautiful) output, but the function that is supposed to ensure the VERSION_PATTERN does not contain any "\n" or "\r" is not implemented. So as you can check the |
As discussed before in #3845, merging this PR may fail due to two tests related to multiline capacities. “test_scan_files_multipline” in file "/test/test_helper_script.py" tests the system to check the multiline capability for two files “dovecot-2.3.14-1.fc34.i686.rpm” and “gnome-shell-41.2-1.fc35.x86_64.rpm” In “extract_and_parse_file”, dovecot file is detected as an executable file, so the test can be fixed through minor changes in #3870. What I realized is that This file should not be detected as an executable file. I think it is related to a bug in the implementation of "Versionscanner.is_executable()". For the second file, the output version pattern is incorrect and contains “\n.” It shows that the multiline-pattern is not supported for non executable files. (I am not pretty sure how we can remedy this) |
RPMs have a SPEC file which contains a bunch of information that looks awfully like the
{vendor, product, version}
tuplet we use for NVD lookups:https://rpm-packaging-guide.github.io/#what-is-a-spec-file
I think it should be possible to read these files similar to the way we read package lists.
For NVD lookup, we would want to intentionally build in some special cases for things like python files which are all packaged with the prefix
python3-
and so on rather than just assuming the name is correct, and maybe trying to do some nice parsing of the url included to see if that can be used to better guess thevendor
.The release-monitoring.org website may help you with names across distros. e.g. https://release-monitoring.org/project/3779/
We might also want to use some data from redhat to see if we can fine tune those mappings: https://access.redhat.com/security/data
Anyone working on this:
This issue is reserved for a participant in the Open Source Hackaton 2023. Please leave it for hackathon participants through the end of April. If it hasn't been claimed by May 5 it will be open to any contributor who wants to work on it.
The text was updated successfully, but these errors were encountered: