Home > Fedora Project, Security > For discussion: Orphaned package in Fedora

For discussion: Orphaned package in Fedora

The Fedora Security Team (FST) has uncovered an interesting problem.  Many packages in Fedora aren’t being actively maintained meaning they are unofficially orphaned.  This is likely not a problem since at least some of these packages will happily sit there and be well behaved.  The ones we worry about are the ones that pick up CVEs along the way, warning of unscrupulous behaviour.

The FST has been plugging away at trying to help maintainers update their packages when security flaws are known to exist.  So far we’ve almost hit the 250 bug level.  Unfortunately we forced a policy that still isn’t perfect.  What do you do with a package that is no longer is supported and has a known vulnerability in it?  Unless you can recruit someone to adopt the package the only responsible choice you have is to retire the package and remove it from the repositories.

This, of course, leads to other problems, specifically that someone has that package installed and they know not that the package is no longer supported nor do they know it contains a security vulnerability.  This morning, during the FST meeting, we discussed the problem a bit and I had an idea that I’ll share here in hopes of starting a discussion.

The Idea

Create a file containing all the packages that have been retired from a repository and perhaps a short reason for why this package has been retired.  Then have yum/dnf consume this information regularly and notify the user/admin when a package that is installed is added to this list.  This allows the system admin to become aware of the unsupported nature of the package and allows them to make a decision as to whether or not to keep the package on the system.

Okay, discuss…

Categories: Fedora Project, Security
  1. 2015-03-26 at 14:38 EST

    The policy I looked at EPEL at one point was two fold. One was the file and a program which reports orphaned packages on the system. The second was a final update to the repo where the package isn’t changed/fixed/etc but has a ‘THIS IS AN ORPHANED PACKAGE’ file. People who have regular updates etc will get notice that this is an orphaned package and if they want they can get it back through packaging it up. The main reason for this was to document the steps to the user needed to why the package was gone and what they could do in the future if they needed to.

  2. 2015-03-26 at 22:13 EST

    Ideally, I would want an update to the yum and createrepo commands (and anything else with similar function) that does the following:

    createrepo –filestatus specialfilestatus.txt

    This could be a simple file that has name value pairs per line, such that you have:

    packagename packagestatus notes

    packagename is just the name of the package in the repo
    packagestatus could be several values: orphaned, warning
    notes could be additional note that you wish yum tools to report before the y/n prompt to start install.

    This would add repo data something like repodata/filestatus.xml to the repo which updated versions of yum could digest and use to present information to the user regarding exceptions.

    There are cases where packages get abandoned, or updates strip out functionality (like Intel’s Haswell microcode update which stripped out cpu functions, so once installed broke haswell identification in libvirt). These are things where we really need an easy way to provide alerts to users that what they are using or about to use may not function as expected.

  3. 2015-03-27 at 09:47 EST

    A tangent, but I like the idea of this sort of systematic review of the packageset. I went through ~80 packages mostly by hand for an F22 Change, and found a handful that hadn’t been touched outside of mass rebuilds since import and maybe an initial set of updates.

    I wonder how many packages are in that state; abandoned by maintainers, users, and upstream, ‘orphaned’ in practice but carried along because they don’t fail to build and are no longer interesting enough to generate bug reports, let alone unresponsive processes.

  4. another fedora user
    2015-03-27 at 12:35 EST

    This is something I am waiting for. Good idea!

    I often run into packages that are multiple versions behind upstream or in a barely usable status. Sometimes the maintainers fix their packages after sending bug reports (e.g. quiterss, exaile), sometimes they don’t (e.g. visualvm, esmtp). I like your idea to suggest the users to uninstall those packages. I have an idea how to automate these things: If a maintainer doesn’t react on any bug reports to his package it will automatically be disadviced after e.g. 200 days. If the bug has a security flag or is an CVE it should be much faster, e.g. after 30 or 50 days.

    But there is another problem below the surface: Maintaining packages seems to be too much work or maintainers easily “quietly orphane” their packages for other reasons. On the long run it would be useful to think about the reasons why this happens.

    • 2015-03-27 at 13:47 EST

      To comment specifically with your last paragraph, I think there isn’t a set of expectations that packagers adhere to. Some just want the software in the repo and think that’s all there is while others feel, myself included, that there should be more responsibility including working with end users to bridge the gap to upstream and actually working with upstream to solve problems.

  5. jt
    2015-03-27 at 21:05 EST

    I like the idea of pushing notifications about package status. There is a definite need to be able to notify consumers/users of packages that have unaddressed vulnerabilities or other issues. I would be interested in seeing some sort of integration with spacewalk/satellite so a notification or report could be generated that provides visibility into an entire environments status.

  6. glawd
    2015-03-30 at 08:08 EST

    Instead of using yum, why don’t you use openscap (not an expert, but it seems to me that coiuld be done) : implement the policy that check the package name and version and print a warning

    • 2015-04-12 at 10:57 EST

      OpenSCAP would work but it’s yet another layer. Incorporating the functionality into yum would make it one-stop shopping.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s