[Auditbeat] Package dataset: Make librpm code compatible across CentOS 6.x, 7.x, and Fedora 29 #10796
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
cwurm
added
review
needs_backport
|
Pinging @elastic/secops |
cwurm
changed the title
adriansr
approved these changes
Feb 18, 2019
cwurm
force-pushed
the
package_librpm_remove_deprecated
branch
from
65797ee
to
64cf6a0
Compare
cwurm
force-pushed
the
package_librpm_remove_deprecated
branch
from
64cf6a0
to
45350b3
Compare
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 20, 2019
…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
added
v7.2.0
and removed
needs_backport
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 20, 2019
…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
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 22, 2019
…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
pushed a commit
that referenced
this pull request
Feb 25, 2019
…ode compatible across CentOS 6.x, 7.x, and Fedora 29 (#10907) Cherry-pick of PR #10796 to 6.7 branch. Original message: 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 #10694 this will hopefully allow RPM package collection to work well.
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
…S 6.x, 7.x, and Fedora 29 (#10796) (#10843) 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 #10694 this will hopefully allow RPM package collection to work well. (cherry picked from commit e7ea5d7)
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
…ode compatible across CentOS 6.x, 7.x, and Fedora 29 (#10842) Cherry-pick of PR #10796 to 7.x branch. Original message: 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 #10694 this will hopefully allow RPM package collection to work well.
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.
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.