[this has been in my drafts folder for some time. But since this topic
came up again in today's meeting, and seeing that others had similar
ideas (I think mhayden or d-caf; already forgot :/), I think it's time
to send it]
So, I thought a bit more about the unresponsive maintainers problem.
The current process, as described in [1] has some obvious problems:
* takes too long
* not fun to chase people around
* wastes time that we can probably make better use of
The provenpackager page [2] lists some rough mechanisms that should take
care of unresponsive maintainers. That looks good initially, but has
shortcomings:
* just shifts the problem from chasing unresponsive maintainers to
semi-responsive provenpackagers.
* looks and feels more like a band-aid solution for a problem that
"shouldn't happen", not like a proper process (for security issues,
at least). The truth is that it's not working, or we simply wouldn't
see the stagnation we're currently seeing.
So, we need to get away from chasing 3rd parties for fixes to doing
fixes ourselves. There should be a quick and easy (by easy I mean no
unnecessary hoops to jump through. Candidates obviously need to proof
that they have the necessary understanding and skills to do this task)
route into a group similar to provenpackagers, but that's allowed to
solely focus on security issues without having any other provenpackager
responsibilities. This idea is scary to people because we may end up
breaking stuff in the process. But think about it: We already have
mechanisms to catch the worst stuff (like the 3 positive ratings
thing). Also, how much worse than an insecure package can it really
be? Mind you, you can still downgrade to the insecure but working
version if things are really messed up badly ... so bottom line, I
don't see a big reason to be concerned.
Presuming that such a policy exists, there may still be problems:
* it can be the case that it's impossible to do a security fix safely
due to ABI changes or other annoyances
* we end up fixing the same unmaintained packages over and over again
So, we need to find a way to deal with those. One option in the
distant future could be something like: If we have to fix an
unmaintained package with security issues X times in a row - add it to
a list. If we have no good way of fixing it, add it to the same list. A
dnf plugin could then compare existing packages or packages about to be
installed to the list of flagged packages and warn the user with a
reason as to why it's a bad idea to install this and that it needs a
new maintainer. Users could still choose to override this, but on their
own risk. Also, this is displayed to actual, active users of the
package, so maybe there is a slim chance that one of them cares enough
to step up as maintainer. If nobody cares ... well, then I guess it
simply wasn't important enough and will just be orphaned.
Now, I'm not saying that anything of this is the ultimate solution,
neither do I expect it to be. I just want a discussion that hopefully
leads us to something better than we have now (and then reiterate).
[1]
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
[2]
https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages
Thanks,
--
Stefan Cornelius / Red Hat Product Security