-
Notifications
You must be signed in to change notification settings - Fork 444
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 files #2964
base: main
Are you sure you want to change the base?
Conversation
Approved tests to run, will be back to review later! |
Codecov Report
@@ Coverage Diff @@
## main #2964 +/- ##
==========================================
- Coverage 81.92% 79.60% -2.33%
==========================================
Files 714 713 -1
Lines 10983 10979 -4
Branches 1476 1278 -198
==========================================
- Hits 8998 8740 -258
- Misses 1599 1830 +231
- Partials 386 409 +23
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 18 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
* fixes intel#2916 Signed-off-by: Bartlomiej Cieszkowski <bartlomiej.cieszkowski@intel.com> Signed-off-by: Przemyslaw Romaniak <przemyslaw.romaniak@intel.com>
cleaned up isort/black/flake8 issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like black thinks there's still an issue in the parser init file. I'm pretty sure I know what it's going to be so I'm just going to suggest/merge a fix now.
Not sure what's going on with the other linux tests (it didn't look like it was related to this PR) but since fixing black will cause them all to re-run I'll get a look at them later today.
from cve_bin_tool.parsers import Parser | ||
|
||
|
||
class RpmParser(Parser): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/srossross/rpmfile also contains a parser if you wanted to reuse anything from that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i just took a look at the lib, and i dont know..
i thought there would be more exception handling, and validation of headers, but its just going over to the next header, and next, not even taking into account 8 byte alignment.. and just searching for the magic pattern, which shouldn't pass as the structure and offsets are well known from fields, i get the feeling that the malformed rpm could pass through it..
i could switch to it, since its used in the project, but i got my doubts about it being strict verifier of rpm
Triggering an odd error: FAILED test/test_scanner.py::TestScanner::test_version_in_package[https://rpmfind.net/linux/centos-stream/9-stream/AppStream/aarch64/os/Packages/-libsrtp-2.3.0-7.el9.aarch64.rpm-libsrtp-2.3.0-other_products458] - AssertionError: glibc found in libsrtp-2.3.0-7.el9.aarch64.rpm. If that's expected, make sure to add glibc to the expected list of other_products.
assert 'glibc' not in {'glibc', 'libsrtp'}
===== 2 failed, 1666 passed, 26 skipped, 42 warnings in 1210.67s (0:20:10) ===== I know that the strings being tested there did come from an rpm but they weren't in rpm format so this shouldnt' have triggered that. I'm going to update the branch and re-run the tests before debugging further. |
this pr parses rpm files for product name and version