#2864 Firejail needs a new maintainer
Closed: Accepted 2 years ago by remyabel. Opened 2 years ago by remyabel.

Hi all,

I apologize if this is the wrong place to put this, but I've seen other issues related to non-responsive maintainers here so I figured this is the most relevant. Currently, the version of Firejail in the repos is 0.9.66 which is over a year old. This by itself would not be an issue, but there is currently a high severity CVE that is patched in newer versions: https://bugzilla.redhat.com/show_bug.cgi?id=2095070

As Firejail is security software, having it remain on an old version this long is unacceptable for most users. a user reached out to the maintainer here: https://bugzilla.redhat.com/show_bug.cgi?id=2120977

Who expressed their desire to transfer maintainership to someone else. I have a COPR for Firejail, but I'm not a Fedora member nor do I want the burden of maintaining the package myself. So I think given the CVE this package deserves some attention.


To be honest the issue is much bigger than this particular package/maintainer.

There are literally dozens if not hundreds of stale packages in Fedora for which updates are neglected or released months after upstream.

I really don't understand why it's the way it is. This needs to be fixed in a unified manner, not by dealing with each particular maintainer personally which may take literally months.

There is no unified way to handle this, because as a community project, we rely on volunteers doing work they're interested and capable of doing. >80% of our contributors are volunteers.

I was about to say the same thing as @ngompa.

There is a new Inactive Packagers policy that will at least find packagers who are completely inactive. There's no conceivable way to check every package out of the 23,125 (source) packages currently in the distro to see if it's stale.

I've also updated firejail as a provenpackager and urged the maintainer to orphan the package. Please test the updates on Bodhi.

I don't see anything for FESCo to do here, unless someone formally starts the Nonresponsive Maintainer Process.

Thanks for the response and pushing the new update. I will close this issue per your last comment.

I had a tangentially related question as coincidentally I noticed the orphaned package issue in Fedora. Given that a couple of maintainers are inactive, there were thousands of orphaned packages in the dashboard. I looked into the upstream monitoring tool and retired packages tool, but I was wondering if there is any way for end users to see if a package is sufficiently outdated? dnf doesn't seem to have a way to be like "this package has a CVE but NOT an update" and the Redhat tool for CVE seems to require you already to know what you're looking for. I guess what I'm asking is, is there a tool an end user can run that says "X amount of packages have deviated from upstream for X amount of months" so they can at least be aware it's outdated and act accordingly.

The only reason why I ask is because I've made the move to start packaging some packages I care about as COPRs due to the security issue I mentioned above. If not, maybe I'll ask in the mailing list.

Thanks for the response and pushing the new update. I will close this issue per your last comment.

I had a tangentially related question as coincidentally I noticed the orphaned package issue in Fedora. Given that a couple of maintainers are inactive, there were thousands of orphaned packages in the dashboard. I looked into the upstream monitoring tool and retired packages tool, but I was wondering if there is any way for end users to see if a package is sufficiently outdated? dnf doesn't seem to have a way to be like "this package has a CVE but NOT an update" and the Redhat tool for CVE seems to require you already to know what you're looking for. I guess what I'm asking is, is there a tool an end user can run that says "X amount of packages have deviated from upstream for X amount of months" so they can at least be aware it's outdated and act accordingly.

The only reason why I ask is because I've made the move to start packaging some packages I care about as COPRs due to the security issue I mentioned above. If not, maybe I'll ask in the mailing list.

Metadata Update from @remyabel:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

2 years ago

I'll respond to you here, but the FESCO tracker is not really the right place for this.


Given that a couple of maintainers are inactive, there were thousands of orphaned packages in the dashboard.

A lot of packages were orphaned recently due to a maintainer who owned many packages stepping down. I'm not sure if that's what you saw, though.
Packages get retired from Rawhide after six weeks of being orphaned if they don't get picked up.

I was wondering if there is any way for end users to see if a package is sufficiently outdated?

You can look at the package's Bugzilla page. Try https://bugz.fedoraproject.org/source_package_name_here or search for the package on https://packages.fedoraproject.org. In addition to user filed bugs, the-new-hotness files bugs for new upstream versions (if it's configured for that package) and Red Hat product security usually file CVE tracking bugs.

Do note that sometimes packages in stable releases are outdated on purpose, as we only push breaking changes to Rawhide.

dnf doesn't seem to have a way to be like "this package has a CVE but NOT an update"

dnf only knows about about what's in the repositories. It's a package manager. It has data on whether currently available updates fix vulnerabilities (e.g. dnf updateinfo), but that doesn't seem to be what you're asking.

is there a tool an end user can run that says "X amount of packages have deviated from upstream for X amount of months" so they can at least be aware it's outdated and act accordingly.

No, but you can query Bugzilla as I said.

I've made the move to start packaging some packages I care about as COPRs due to the security issue I mentioned above.

It would be better to sign up to be a packager and help out directly.

Login to comment on this ticket.

Metadata