In today's Fedora CI meeting, we discussed an annocheck gate. rpminspect has
annocheck functionality on its roadmap. bookwar asked that I post a message
explaining what rpminspect does for ELF checks and what is planned. So here
What is rpminspect?
The important things to know for the context of this email are that rpminspect
allows us to run tests against Koji build output as well as compare two Koji
builds and report changes. rpminspect itself is a command line tool.
What does rpminspect do with ELF files?
A number of tests are performed on ELF files. The basic design here is
inherited from rpminspect's ancestor--rpmdiff (the internal Red Hat service,
not the other rpmdiff). These tests are:
* Check for execstack in ELF shared objects and executables
* Check for TEXTREL sections in ELF shared objects, which means the build
* Check that '-z relro -z now' was used for linking
* Check that -D_FORTIFY_SOURCE was used when compiling
* Check for use of any forbidden IPv6 networking functions (list in
* In ELF .a libraries, check to see that the object members were built
In cases where rpminspect is comparing two builds, the above tests extend a
bit and the messages report whether or not a desired feature was lost in the
after build or an undesired feature was gained.
What is planned for ELF in rpminspect?
I am still reviewing rpminspect's ancestor for test ideas that make sense to
port forward to the grand world of CI. Right now that involves looking at the
following things that rpmdiff still does:
* Runs elflint when comparing two builds and reports a regression if the
output differs between the before and after builds.
* Runs annocheck when comparing two builds and filters its results up
* Reports executables that gain or lose PIE.
* In shared libraries, gathers symbols in before and after builds and
reports what was gained or lost for ABI verification.
Of these, the annocheck one is the most interesting to me and most relevant I
feel. It's also easy to add to the current battery of ELF tests in
rpminspect. It makes sense to me in rpminspect because we gain the ability to
compare results between builds in addition to validating single builds against
None of these planned ELF tests are particularly difficult. I already did the
I have bumped up these tests in my own priority list for rpminspect so we can
get that functionality out there faster.
Questions or Thoughts?
Have other ideas or questions? Change in prioritization? Want to help with
code or the integration test suite for rpminspect? Let me know.
The integration test suite is written in Python and I could really use
contributions there to work through various permutations of build types and
errors. The more people contributing there, the better. This is one reason I
have not introduced new inspections recently because I have been working on
building out the integration test suite for all existing inspections.
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT