[Auditbeat] Cherry-pick #10796 to 7.x: Package dataset: Make librpm code compatible across CentOS 6.x, 7.x, and Fedora 29 #10842
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…S 6.x, 7.x, and Fedora 29 (elastic#10796) Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with elastic#10694 this will hopefully allow RPM package collection to work well. (cherry picked from commit e7ea5d7)
cwurm
changed the title
|
Pinging @elastic/secops |
adriansr
approved these changes
Feb 22, 2019
You're right, it should have had one originally. I just spoke to Andrew, and we decided to backport this all the way to 6.7 (I just opened #10907). So the package dataset will include this from its first release. Since there will be no change to released functionality I think we should be fine without a changelog entry. But happy to add one if you think it makes sense. |
|
Nevermind, I thought it had been released already. 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of PR #10796 to 7.x branch. Original message:
Librpm version 4.14.2.1 on Fedora 29 no longer contains the
headerGetEntrymethod we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a).Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like
rpm_tag_t/rpmTag/rpmTagVal.This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between):
headerGetString/headerGetNumberinstead ofheaderGetEntry.int32_tinstead ofrpm_tag_t/rpmTag/rpmTagVal. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible.It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error.
Together with #10694 this will hopefully allow RPM package collection to work well.