Thursday, September 19, 2019

rpminspect-0.6 released with new inspections and bug fixes

There are three new inspections implemented in rpminspect-0.6:
  • The upstream inspection compares SRPMs between before and after builds to determine if the Source archives changed, were removed, or new ones added.  Anything listed as a Source file in the spec file is examined and not just tarballs.  Source file changes when the package Epoch and Version do not change are considered suspect and need review.
  • The shellsyntax inspection looks at shell scripts in source and binary packages and runs them through the syntax validator for the indicated shell (the -n option on the shell command).  The shells that rpminspect cares about are in the shells list in the rpminspect.conf file.  This inspection reports scripts that fail the syntax validator or scripts that were good but are now bad.  If you had a bad one and it's now good, you are notified only.
  • The ownership inspection enforces some file owner and group policies across builds.  The rpminspect.conf settings of bin_owner, bin_group, forbidden_owners, and forbidden_groups are all used by this inspection.  A typical use of this inspection is to ensure executables are correctly owned and that nothing is owned by mockbuild.
This release also includes a lot of bug fixes.  I really appreciate all of the feedback users have been providing.  It is really helping round out the different inspections and ensure it works across all types of builds.

For details on what is new in rpminspect-0.6, see the release page.

There is also a new release of rpminspect-data-fedora which includes changes necessary for the new inspections.  See its release page for more information.

Both packages are available in my Copr repo.  I am doing Fedora builds now, which includes Fedora 31.  If you want another release of Fedora to have builds, let me know.

Sunday, September 8, 2019

github notifications

I have noticed that a number of projects I have on github have stopped notifying me.  I have not yet found a pattern or missed setting, but it is possible I am looking in the wrong place.  I do get notifications for some projects, just not all.  And this goes across projects that are under my personal account as well as projects that I am a member of but exist elsewhere.

Has anyone seen this with github?  Any tips on receiving consistent notifications?  I am wanting to receive notifications of Issues (both new issues and comments posted), Pull Requests, commits, tags, and releases.

Friday, September 6, 2019

rpminspect-0.5 released, two new inspections and some bug fixes

[I would have posted this roughly 18 hours ago when I made the release, but the fire alarm went off in the office and, well, that sort of had this wait until today.]

rpminspect-0.5 is now available.  The releases are noted on the github project page.  I uploaded the tarball there.  I have done builds in Fedora rawhide and the f31 branch.  For other releases, you will need to use the Copr repos.

Bug fixes and general improvements:
  • Support running rpminspect on local RPM packages (#23). You may now specify a local RPM or SRPM as the input for rpminspect. If you specify a before and after file, rpminspect will assume they are peers and will perform applicable inspections.
  • Adjust the 'text' output mode by adding some extra blank lines for readability.
  • For the 'changedfiles' inspection, get the list of possible C and C++ header file endings from the header_file_extensions setting in rpminspect.conf.
  • Add dnf instructions to the README file to help get the development packages installed on Fedora or RHEL.
  • Prevent a crash in get_product_release() when the build specification lacks enough information to infer a product release (e.g., a Koji build ID).
  • Start an integration test suite in the tests/ subdirectory.
  • Adopt a Code of Conduct for the project, see CODE_OF_CONDUCT.md
  • Move the data/setuid subdirectory to data/stat-whitelist. The files will be installed to /usr/share/rpminspect and the stat-whitelist subdirectory provides information on file modes, owners, and groups for known setuid/setgid files.
  • Process a [vendor-data] section in the configuration file which contains paths to locations provided by the rpminspect data package.
  • Fix configuration file detection in rpminspect.
New inspections:
  • removedfiles

    Only runs when you are comparing a before and after build.  The general inspection is to report when files were removed from a package.  That is, it was present in the before build, but gone in the after build.  There are some additional checks and reporting:

    • If the removed file was an ELF shared object, rpminspect reports it as a RESULT_BAD noting it may be a potential ABI break.
    • Files removed from a security path prefix are also marked as RESULT_BAD and as WAIVABLE_BY_SECURITY. All other removals are reported as RESULT_VERIFY.

    The security path prefixes are set in the rpminspect.conf file in the security_path_prefix setting.  This is the sort of thing that changes over time as well as varying across similar products.
  • addedfiles

    Kind of like the opposite of removedfiles, but does a little more. The main thing is to catch any accidental additions to packages as well as additions to security path prefixes:

    • Ignore the debuginfo and debugsource paths.
    • Ignore anything with .build-id/ in the path.
    • Ignore Python .egg-info files since these come and go and sort of always change.
    • Report files added to /tmp or /var/tmp path prefixes as RESULT_BAD.  The forbidden_path_prefixes list can be set in the rpminspect.conf file.
    • Report files added that end with ~ or .orig as RESULT_BAD.  The forbidden_path_suffixes list can be set in the rpminspect.conf file.
    • Report any __MACOSX, CVS, .svn, .hg, or .git directory added as RESULT_BAD.  The forbidden_directories list can be set in the rpminspect.conf file.
    • Any files added to a security path prefix are reported as RESULT_VERIFY and WAIVABLE_BY_SECURITY.
    • Any setuid and/or setgid file added is reported as RESULT_INFO if the file is on the stat-whitelist and the expected permission mode matches.  If they do not match or the file is not on the stat-whitelist, it is reported as RESULT_VERIFY and WAIVABLE_BY_SECURITY.

    Most of the settings for this inspection are in rpminspect.conf, with the exception of the stat-whitelist which is per product release and comes from the data package.
There is also a new rpminspect-data-fedora release which contains an updated rpminspect.conf file with the new sections and settings.  It also contains the stat-whitelist subdirectory with files for recent Fedora releases.

In the addedfiles inspection, the check for __MACOSX subdirectories is deliberate and comes from the ancestor of rpminspect.  In theory, you could build noarch RPMs on MacOS X and then install those on Fedora.  In those cases, we want to make sure you do not accidentally package up a __MACOSX subdirectory.

Builds are available in Copr as well as the f31 and rawhide branches.